Hey everyone ! I finally decided to monitor my applications more closely with Grafana. However I’m having issues building dashboards their logs.
Their logs are currently sent over syslog (in RFC3164 format) into telegraf. But it simply puts the whole message into the message field, so I can’t use specific fields (eg. URL for httpd, source IP for DNS requests, username for SSH, …) to build graphs.
I’ve read about grok patterns, but I have no idea how to use them.
Would someone have any pointer on how I could make sense out of these logs for later use ?
I have a similar setup (all hosts sending logs through syslog protocol to a central collector), but the collector is graylog. A few years back it used to use Grok expressions, but now it has its own filter syntax. My notes on extractors/grok patterns are still there (unfold details). Can’t help you much more than that, sorry!
I’ve found that you can use custom grok patterns to parse logs just as grayling extractors do. I’m still trying to figure it out, but so far I could start parsing logs using a [[processor.parser]] block. I’ll document my findings when I get it working as I want it.
I store and query them using influxdb. I checked Loki but apparently it’s main feature is that it store the message as a single field, this not parsing the log at all. I didn’t know about Promtail. Is it better suited than influxdb for my usecase ?
I don’t think Loki itself parses logs on ingestion at all. I’m not sure if Promtail can ship logs to influx, I’ve only ever used it to ship to Loki. Promtail can be configured to add or parse or labels from the logs it sends, or you can just parse them at query time using builtin parsers like logfmt, json or regex. The hard part here will be figuring out the query to pull out the metrics you want to graph, which sounds like where you’re stuck already. So it’s hard to say which is actually better suited here.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: [email protected]
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
I have a similar setup (all hosts sending logs through syslog protocol to a central collector), but the collector is graylog. A few years back it used to use Grok expressions, but now it has its own filter syntax. My notes on extractors/grok patterns are still there (unfold
details). Can’t help you much more than that, sorry!It does help thank you ;)
I’ve found that you can use custom grok patterns to parse logs just as grayling extractors do. I’m still trying to figure it out, but so far I could start parsing logs using a
[[processor.parser]]block. I’ll document my findings when I get it working as I want it.You said you’re using telegraf, I assume to collect them - where are you storing/querying them? Have you looked into using Loki/Promtail for this?
I store and query them using influxdb. I checked Loki but apparently it’s main feature is that it store the message as a single field, this not parsing the log at all. I didn’t know about Promtail. Is it better suited than influxdb for my usecase ?
I don’t think Loki itself parses logs on ingestion at all. I’m not sure if Promtail can ship logs to influx, I’ve only ever used it to ship to Loki. Promtail can be configured to add or parse or labels from the logs it sends, or you can just parse them at query time using builtin parsers like logfmt, json or regex. The hard part here will be figuring out the query to pull out the metrics you want to graph, which sounds like where you’re stuck already. So it’s hard to say which is actually better suited here.