1 |
On 20/02/2014 11:16, Yuri K. Shatroff wrote: |
2 |
> |
3 |
> |
4 |
> 20.02.2014 09:24, Canek Peláez Valdés пишет: |
5 |
>> [ snip ] |
6 |
>>> but I do not see the point, beyond as a nice gimmick. |
7 |
>> |
8 |
>> Well, I *do* see a point. Many points, actually. You want the logs for |
9 |
>> SSH, from February 12 to February 15? Done: |
10 |
>> |
11 |
>> journalctl --since=2014-02-12 --until=2014-02-15 -u sshd.service |
12 |
>> |
13 |
>> No grep. No cat. No hunting logrotated logs (the journal will rotate |
14 |
>> automatically its logs, and will search on all logs available). You |
15 |
>> can have second-precision intervals. |
16 |
>> |
17 |
>> Also, the binary format that the journal uses is indexed (hence the |
18 |
>> binary part); therefore, the search is O(log n), no O(n). With a log |
19 |
>> with a million entries, that's about 20 steps. |
20 |
>> |
21 |
>> Perhaps it's just a gimmick to you. For me is a really usefull |
22 |
> |
23 |
> Clearly, it's reinventing a wheel. All that indexing stuff and O(log(n)) |
24 |
> if really needed is easily achieved with databases. |
25 |
> Not using cat and grep is not something one'd boast; rather, again, a |
26 |
> waste of resources to recreate already existing tools. |
27 |
> BTW, I wonder if anyone does really have logs with millions of lines in |
28 |
> one single file, not split into files by date, service etc, so that the |
29 |
> whole O(n) issue is moot. |
30 |
|
31 |
I have logs like that. It's not an uncommon scenario. |
32 |
|
33 |
> Well, maybe it'd be nice to have a collection of log management tools |
34 |
> all-in-one but beyond that I don't see any advantages of systemd-journald. |
35 |
|
36 |
The immediate feature-add that syslog needs is arbitrary facilities, not |
37 |
the 16 fixed ones in syslog() system call. |
38 |
|
39 |
|
40 |
>> Its raison d'être is the new features it brings. |
41 |
> |
42 |
> I didn't notice any new features. It's not features that are new, but |
43 |
> just a new implementation of old features in a more obtrusive way IMO. |
44 |
> |
45 |
>>> Additionally, the use of "tail -f" and "grep" allows me to check the |
46 |
>>> logs |
47 |
>>> real-time for debugging purposes. |
48 |
>> |
49 |
>> journalctl -f |
50 |
>> |
51 |
>> Checks the logs in real time. Again, [1]. |
52 |
> |
53 |
> Again, a brand new Wheel(c) |
54 |
> |
55 |
>> systemctl status apache2.service |
56 |
>> |
57 |
>> (see [2]) will print the status of the Apache web server, and also the |
58 |
>> last lines from the logs. You can control how many lines. You can |
59 |
>> check also with the journal, as I showed up. |
60 |
> |
61 |
> I believe it would be a 5-minutes job to add the capability of printing |
62 |
> last N log entries for a service to `rc-service status`. Using cat, grep |
63 |
> and the like. |
64 |
|
65 |
|
66 |
No, that will not work easily for all definitions of easily. |
67 |
|
68 |
rc-something has zero control over where the logs go and no standard |
69 |
method to provide "hints" to the logger. Gentoo ships syslog* configs |
70 |
that basically stick everything in messages, where grepping them out is |
71 |
a PITA. I usually rewrite that config more to my taste and needs and |
72 |
rc-service cannot know what I did. So the idea fails at step 1 as the |
73 |
code does not know where the logs are. |
74 |
|
75 |
|
76 |
> Not reinventing wheels. Not spending super-talented |
77 |
> super-highly paid developers' time on doing tasks one had done about 30 |
78 |
> years ago. I believe, not having this option is due to its simple |
79 |
> uselessness. |
80 |
|
81 |
30 years ago we had isolated stand-alone machines without nothing like |
82 |
the logging needs we have today. Whilst I agree with you that systemd's |
83 |
logging tools may not be the solution, I can assure you (as someone who |
84 |
has to deal with this shit) that syslogging in the modern world is a mess. |
85 |
|
86 |
Try this: Decide you cannot afford Splunk, so do it yourself. Now get |
87 |
your Apache access logs into the same searchable database your other |
88 |
stuff is in, and do it in such a way that you can SELECT what you want |
89 |
out in obvious ways. |
90 |
|
91 |
Repeat for every other app you have that logs stuff. Remember to find |
92 |
the really important logs which are usually sitting in /opt/ and |
93 |
produced by Log4Perl or something equally abominable. |
94 |
|
95 |
|
96 |
> |
97 |
> This way I really wonder if at some point the super talented systemd |
98 |
> programmers decide that all shell tools are obsolete and every program |
99 |
> should know how to index or filter or tail its output in its own, |
100 |
> though, open, binary format. I can't get rid of the idea that systemd |
101 |
> uses the MS Windows approach whatever you say about its open source. |
102 |
> |
103 |
|
104 |
|
105 |
-- |
106 |
Alan McKinnon |
107 |
alan.mckinnon@×××××.com |