New user - looking for information on parsing fields from Syslog message field
We’re just starting to get LogicMonitor setup on our network and, mainly to test the collector, I setup one of our HAProxy instances to forward it’s syslog to the collector and can confirm that the logs are being ingested. However, because it’s bare syslog, all I can see is the bare message field. What I’m looking for is the functionality to pull particular fields out of the message and into fields. <134>Oct 17 23:37:17 haproxy[3719288]: 69.141.121.67:11058 [17/Oct/2023:23:37:17.568] http_front_80 http_back_80/Acc-SRV01 0/0/0/32/32 200 759 - - --NI 5825/3042/52/12/0 0/0 "POST /Server/URL.asmx HTTP/1.1" For example, in the log line above, the fields are separated by a space. Among the fields included in the log line are items such as the Client IP, the FronteEnd and BackEnd which I was hoping to be able to extract into their own fields to help with reporting. I’ve been looking through the documentation and have found the LogSource section but that doesn’t seem to be adding the field. Frankly, after a few hours of searching and experimenting, I’m hoping someone could give me some guidance on how this can be done. ThanksSolved370Views19likes11CommentsParse syslog facility and priority
Syslog that adheres to the standard format that has been around for decades prefixes the message with a number between greater than and less than symbols. For example: Thatvalue is the result of combining two different numbers: facility and priority. We can decode this facility and priority number pretty easily. Let’s take 164 for example: 164 in binary is “1010 0100”. The facility is extracted by taking the first 5 digits of 164 in binary, “10100” and converting to decimal, 20. Looking that up in a standard table, we can see that 20 corresponds to a facility of local4. The priority is extracted by taking the last 3 digits of 164 in binary, “100” and converting to decimal, 4. Looking that up in a standard table, we can see that 4 corresponds to a priority of Warning. LM Logs has the ability to extract this number from the log message. It’s pretty easy since all you do is pipe the search query into the parse operator: This puts the number into its own column, in this case called severity. What I’d like to do is: Take the value in the severity column and convert it to binary. Then take the first 5 digits and convert to decimal and show that as a separate field on the log. Take the value in the severity column and convert it to binary. Then take the last 3 digits and convert to decimal and show that as a separate field on the log. I’d love the ability to embed the mapping found in the standard table so that instead of displaying the number it displayed the name of the facility and priority. Since pretty much all Syslog follows this format and uses the standard table, it might be worth it for LM to build this kind of capability into LM Logs if it doesn’t exist today. All customers who do syslog streaming into LM Logs would benefit from having the facility and priority parsed out into human readable words. What I’m thinking is a couple of new operators in the query language: dec_to_bin(x) - converts a decimal number (x) to binary bin_to_dec(x) - converts a binary number (x) to decimal left(myStr, x) - grabs a specified number of characters (x) from the left part of a string (myStr) right(myStr, x) - grabs a specified number of characters (x) from the right part of a string (myStr) mid(myStr, x, y)- grabs a specified number of characters (y) from a string (myStr) starting at a certain character index (x) str(x) - converts an object (x) into a string so that it can be used as an argument in left, right, mid functions lookup(x, myDictionary) - looks up a value (x) in the keys of a dictionary (myDictionary) and returns the value of the dictionary entry Alternatively, or in addition: parse_facility(msg) - extracts the facility and returns the human readable facility name (basically doing in one step what I’d do manually with the functions above) parse_priority(msg) - extracts the priority and returns the human readable priority name (basically doing in one stepwhat I'd do manually with the functions above)23Views3likes0CommentsELK as a Service
One thing everybody is looking for is convergence, a single tool that does everything for observability. Monitoring, metrics, log analysis - LM does a good job on the first two, but I still need a separate tool to get useful metrics and trends out of my application logs. LM should look into adding ELK-as-a-Service to the LM feature stack (provide customers with an API endpoint they can feed logs to or something), and then customers could have service-level monitoring (URL response times, etc.), plus the traditional LM suite of monitors/metrics, plus LM Cloud, *plus* the most useful info of all: data mined from application logs. That's generally where the really good insights come from (and most of what's unique to each customer's business/offering). ELK is well-known, open source, and fairly mature. Relatively easy to scale as well; should be easy for LM engineering to put together for a proof of concept anyway. Meanwhile, I'm looking at things like Papertrail, Librato andLogz.iofor my application logs - but I'd really like to have One Tool to Rule Them All.4Views0likes1CommentSecure syslog forwarding to LogicMonitor via TLS
Our team has verified that secure syslog forwarding (via TLS) is not supported currently and would like to submit a feature request to LogicMonitor DEV team to asseswhether securesyslogforwarding can be implemented. An example will be syslog-ng forwarding secure (i.e. encrypted) syslog messages to LogicMonitor collector. https://www.balabit.com/documents/syslog-ng-ose-latest-guides/en/syslog-ng-ose-guide-admin/html/concepts-tls.html This will enable centralized logging server to forward secure syslog messages to LogicMonitor collector then. Thanks & Best Regards, Horace31Views3likes0CommentsSyslog "Cleared" = MEANINGLESS
Syslog Issues: #1. The person who asked to have SYSLOG present a "cleared" message.....CLEARLY does not understand that a SYSLOG is NOT A tracked condition like an OID value is....it is a SINGLE SPOT in time....and event that "happened" and does NOT "clear" as you can't change the past. #2. The programmers HONORING that (deeply flawed) request frustrates me to no end.....team, I get the mantra "the customer is always right" .....except when they're wrong it is in EVERYONE's best interest if you retrain the un-skilled users in what a baseline understanding should be. I have no tolerance for bad design making it into development when people should know better. #3. You should have provided those of us who know better, a way to OPT OUT of these bad design decisions.7Views0likes3CommentsSyslog Timestamps and RFC's
Syslog issues: 1. Being bound to only the two RFC for syslog is near sighted: syslog / timestamp / formatting should be more flexible. 2. the biggest concern I have is that Syslog should reflect the time stamp of the COLLECTOR'S NIC at the time the syslog packet ARRIVES at the collector....not the syslog / timestamp of the system sending the message : this is especially important with systems where clock settings or NTP are currently failing......alerting is based on the time stamp : if the time stamp says Jan 1st 2001 12:01am becasue the CMOS battery on the unit failed......than we NEVER see those syslog messages due to alerting range.8Views0likes0CommentsNotice message - Syslog Alerting
LogicMonitor Ticketrequest (50445) Currently the platform only supports syslog alerting for messages equal to and above Warning Level. Syslog messages below Warning are ignored. (Notice, Informational, Debug) We would like to have Notice and potentially even Informational syslog message alerts available on the LogicMonitor platform. Whats the reason for the feature request ? Many network devices have important syslog messages classified as Notice by default. Here are just some examples I have found personally on our Juniper devices. VCCPD_PROTOCOL_ADJDOWN OSPF NEI DOWN SSHD_LOGIN_FAILED LOGIN_FAILED LACPD_TIMEOUT This is just one Platform. Juniper does allow you to reclassify syslog messages to any severity level you want but its not a scalable solution. Also some platforms don't allow you to change classification at all (Palo Alto)9Views0likes1Comment