Exactly. I have my reservations on whether we as mainframe folks are choosing this (log analytics products) or are defaulting to it because no one is challenging for appropriate options from the mainframe technical side. For an org, there is of course the valid point of correlation that Charles mentions, however, if you objectively work out costs and that, I don't think it works out as cost-effective.
We may see kubernetes platforms sending auth logs, syslog, and whatever else to log analytics, but they don't send system metrics. Time-series data is a different beast altogether. However much elastic/splunk/whoever else says they also do metrics, they're only secondary features at best. There's a reason time-series databases exist, and are necessary. On Wednesday, March 6th, 2024 at 20:48, Dave Beagle <00000525eaef6620-dmarc-requ...@listserv.ua.edu> wrote: > We used Splunk at a former employer. Well, not really used it. An auditor > “suggested” we implement it to “improve” our mainframe security. The auditor > knew nothing about mainframe security. Likely read about Splunk somewhere or > saw a session on it at a conference. And of course the topic of “security” is > at the top of the heap among executives who wouldn’t know Top Secret from > ACF2 from RACF. Especially when they hear that other companies are being > hacked or blackmailed in the media nearly every day. > > > Sent from Yahoo Mail for iPhone > > > On Wednesday, March 6, 2024, 10:02 AM, kekronbekron > 000002dee3fcae33-dmarc-requ...@listserv.ua.edu wrote: > > > I guess you might say that the whole point of products such as these is > > converting dense "strings & numbers" into logs. > > I agree, except that I think the goal is not to squirrel metrics into logs, > but to get metrics and/or logs (actual SYSLOG) to tooling used outside of > mainframe. > > > no, we want to manage mainframe security 100% on the mainframe" and that > > may be valid, but not every enterprise feels that way. > > Not saying this, I certainly see the value in common tools, especially if it > means adopting good tech from distributed. > > I just don't see how high volume metrics (even if we filter down to just a > few 100, from all SMF types) can be equated to more or less logs, and handle > them like that, except because it's already in use elsewhere in the org. > Instead of chosing the right tool for the job. > > > > On Wednesday, March 6th, 2024 at 20:20, Charles Mills charl...@mcn.org wrote: > > > I guess you might say that the whole point of products such as these is > > converting dense "strings & numbers" into logs. A mainframe security > > "event" is surely as significant to the enterprise as a Linux server > > security event -- it makes sense to many enterprises to get it into their > > enterprise security analysis solution (Splunk, Sumo Logic, or a "SIEM"). > > You may say "no, we want to manage mainframe security 100% on the > > mainframe" and that may be valid, but not every enterprise feels that way. > > I feel that there is a benefit to correlating the two worlds, and > > correlation is what SIEMs and Splunk are good at. In other words, it may be > > relevant that the mainframe is seeing hundreds of invalid password attempts > > at the same time that a Linux server is seeing DoS attacks. > > > > When you think of SMF you may primarily think in terms of job accounting > > and resource management, but the first record type that customers usually > > want to export to Splunk or a SIEM is RACF's type 80. > > > > Yes, SMF is very "dense" and Syslog -- the industry standard logging > > "thing" -- too loosely defined to be called a standard, and not to be > > confused with what we mainframers call SYSLOG -- is basically > > human-readable ASCII text and not very dense at all. The most common format > > is some variant of tag = value, so one binary byte at offset 20 into an SMF > > 80 record might become EventCode = 1 or perhaps Event = RACINIT. > > > > It's a big job. I just looked. At the point I turned the product over to > > BMC it consisted of about 100,000 lines of C++, 26,000 lines of assembler, > > and 60,000 lines of a proprietary schema that mapped, for example, a binary > > byte at offset 20 in an SMF 80 record, to EventCode = nn. > > > > Charles > > > > On Wed, 6 Mar 2024 02:15:14 +0000, kekronbekron kekronbek...@protonmail.com > > wrote: > > > > > I don't understand this at all... we all know that SMF is not a log, it's > > > a whole bunch of strings & mostly numbers... metrics. > > > Why has it become acceptable to send metrics to a log search tool, > > > knowing full well that these are different categories with different > > > solutions. > > > Splunk etc. are meant to collect and search through things like http web > > > server log, not metrics. > > > The information density in a log is low. In SMF, it's very high (there > > > are no fluff words, just metrics which may or may not be of use during a > > > given activity). > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
