1 |
On 10/31/2014 06:30 PM, Rich Freeman wrote: |
2 |
> On Fri, Oct 31, 2014 at 6:09 PM, Tom H <tomh0665@×××××.com> wrote: |
3 |
>> The systemd line was always that if you wanted to ship your logs off |
4 |
>> to another box, use rsyslog. So I've never understood the embedding of |
5 |
>> an httpd in systemd. I guess that the httpd server's useful if if you |
6 |
>> want a basic send-the-logs-to-another-box-as-is, but that, if you want |
7 |
>> to filter or manipulate the journald output, you have to use rsyslog |
8 |
>> or syslog-ng. |
9 |
>> |
10 |
> If you're going to implement a log manager there is no reason to not |
11 |
> let it export logs to a central manager. |
12 |
> |
13 |
> As far as filtering/manipulating logs goes, you can do plenty of that |
14 |
> with journalctl already, and it supports dumping your logs in json so |
15 |
> you can do anything you want with them in another tool. There aren't |
16 |
> really any such tools around yet, but I'm sure we'll see them come up. |
17 |
|
18 |
You guys should check out the ELK stack: |
19 |
http://www.elasticsearch.org/overview/ |
20 |
|
21 |
Basically, transform logs to JSON with logstash, throw the JSON into |
22 |
elastic search, and make plots with Kibana. We use it at work; it's |
23 |
absolutely fantastic. |
24 |
|
25 |
You can save Kibana dashboards and have them auto-update every 5 or 10 |
26 |
seconds (plenty of other granularities as well), and have a "real-time" |
27 |
view of, let's say, job errors or running jobs or utilization. |
28 |
|
29 |
Alec |