1 |
On 02/09/2015 08:02 AM, Rich Freeman wrote: |
2 |
> Keep in mind that if you're grepping logs, there is probably a better |
3 |
> way to accomplish what you want to do with journalctl's options. |
4 |
> Finding all output from a particular daemon is going to be more |
5 |
> reliable if you filter by unit, versus getting verbose log output from |
6 |
> your mail server that has "mysql" somewhere in it or whatever. That |
7 |
> is the main reason for using a binary log format. |
8 |
|
9 |
Of course, of course. I should have expanded a little more, but I was on |
10 |
my way to work out. I don't use systemd at work, but for my server I |
11 |
generally find the most helpful command to check a particular service is |
12 |
`systemctl status <service>` to see how it got screwed up. I imagine it |
13 |
would be pretty useful to grab the JSON output from every host and put |
14 |
it in elastic search or mongodb or something, but I don't have any |
15 |
experience doing that. At the same time, though, the message would still |
16 |
have to be parsed by something and a lot of the metadata looks to be not |
17 |
extremely useful (atm anyways). |
18 |
|
19 |
> If you're using an automated tool you can also use cursors to bookmark |
20 |
> the last entry you read and then ask journalctl for entries since that |
21 |
> one. Of course, an automated tool would probably just read the logs |
22 |
> via dbus or whatever (I haven't taken the time to look into the APIs). |
23 |
> |
24 |
|
25 |
Using the low-level DBus C API makes me cry just a little bit; I've been |
26 |
doing a ton of DBus stuff to add good systemd support to bossman. That |
27 |
said, the API systemctl exposes over DBus is pretty common-sensical, so |
28 |
I'm sure the journalctl one is straightforward as well. |
29 |
|
30 |
Alec |