6 ms·

I wasn't aware of extrahop so I will have to look into that. We currently use Solarwinds Orion which is where status gets some of its data. We have definitely

I wasn't aware of extrahop so I will have to look into that. We currently use Solarwinds Orion which is where status gets some of its data. We have definitely outgrown Orion, and a lot of stuff in Orion is very rough, sloppy, and not well integrated. We don't really like the idea of cloud hosted monitoring (which is a lot of what more modern monitoring systems are). Alternatives also seem very expensive. So if we are going to make a investment (cash or labor) I would rather we get a system that fulfills all of our needs (fit) and share it with everyone.

dvanduzer 13y ago
Had you tried Nagios and Puppet/Chef when you started developing these? The logging tool is the only one I'm not sure about, if you're parsing 1200 events a second. I'm not familiar enough with Orion to understand why it was insufficient. Would you say these in-house tools are primarily about integrating / presenting the data, or are there custom parts doing more heavy lifting too?
- KyleBrandt 13y ago
  We use Puppet a lot and are generally quite happy. We have recently started leveraging Hiera which is addressing our main issue we had with Puppet: Reusability problems in the code since Modules (code) and our data were not easily separated. A lot of these tools are about integrating / presenting but that isn't entirely the case. Status does its own polling of things like Redis and SQL. Realog parses the data, structures it in Redis etc, and the patching dashboard can kick of updates.
  - dvanduzer 13y ago
    Status handles the scheduling of the polling, or the actual polling, or both? One thing Nagios handles well, although it isn't exactly well polished, is distribution, scheduling, and aggregation of the polling. Also, anecdotally, "nobody" seems to know how easy it is to do simple-intermediate monitoring of MS-SQL in Nagios. I happen to be using this, at the moment: https://github.com/scot0357/check_mssql_collection https://github.com/scot0357/check_mssql_collection edit: And thank you for the concise explanation of Hiera. I had entirely ignored it as just another add-on as Puppet "goes enterprise"
- stevenjmurawski 13y ago
  We tried Nagios a while back, before going to Orion. Nagios has some great structural ideas, but fell down in other areas (don't know all of them, that was before I came on board). We use Puppet to manage our Linux infrastructure and are testing Desired State Configuration for our Windows systems. Puppet and DSC solve a different problem than monitoring. Our tools span the gamut of aggregating and presenting data, to doing "heavy lifting" of things like installing patches, managing our load balancers, and removing bad query plans from our database servers. Our in-house tooling fills in gaps where existing tooling wasn't responsive enough or made it difficult to deal with certain edge cases. General purpose tools like Orion satisfy 80% of our use cases, but we are fanatical about performance and functionality so we want to fill in that additional 20%. In fact, the majority of our Orion monitors are custom script monitors, which we have to create ourselves as it is. If what we do can work for others (I've worked in several environments with Orion and had the same issues in each environment), that's a bonus. We've found we are building a significant number of these projects and that's why we are looking for a dedicated developer for our team.
  - dvanduzer 13y ago
    I'll have to look at the overlap between Puppet's Windows tools and DSC. These are definitely distinct from monitoring, but monitoring configuration should be populated from the same configuration store as Puppet. (Sometimes Puppet is the configuration store.) I've never evaluated Orion in particular, but it's slightly puzzling if you're creating a lot of custom monitoring scripts. In the low-touch Nagios deployments I've seen, this is often because someone didn't understand good places to use macros, and centralize more of the parameters.
    - jacques_chester 13y ago
      The problem is due to history. Configuration systems have historically looked at config as bits-on-a-disk. Supervisor systems look at bits-in-memory. And they emerged and evolved independently. So there's pain points and impedance mismatches regardless of which one you start with. What's needed is a system that sees that configuration and supervision are the same problem: you have a directed graph of what a system can look like, plus a compare-and-repair mechanism to drag the system to that state frequently. I've personally looked at Chef, Puppet and Cfengine, none of which really does all of them the way I would like. http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/ http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...
berkay 13y ago
"We don't really like the idea of cloud hosted monitoring" Can you elaborate on the reasons?
- DougWebb 13y ago
  I'll bet one of the reasons is the amount of data. At a previous employer I built a system similar to this which produced nightly, weekly, monthly, and annual reports of weblog analysis for an app that had 6 million+ http requests per day. It was tough enough to consolidate those logs across the load-balanced servers in a single data-center. We never consolidated across data-centers (separate reports for each instead) and I doubt we could have shipped all of that data to a cloud service in a reasonable amount of time. BTW, we made heavy use of setting and logging http headers too. One trick I liked was capturing performance timing metrics as a request was processed and stuffing it into a response header as the response went out. We then logged the response headers, which gave us the ability to report on the performance metrics. We also had a debug mode in the app on the browser side so we could see the performance metrics from the headers there too.
  - dvanduzer 13y ago
    When was this? ~70 events per second doesn't sound like much to capture and aggregate. How much of this parsing did you need to perform in real time? Creating a unique token to pair requests/responses shouldn't add much overhead at all.
    - DougWebb 13y ago
      Development started around 2000, and stabilized around 2008. As far as I know the reporting scripts are still being run every day. During this period we had purchased a 1TB storage rack from EMC for a million dollars, to give you some perspective on the differences between then and now. - No real-time parsing; it's all nightly batch processing after devops rotates the Apache server logs to a storage volume. The logs sit there for a while then get compressed and moved to offline tape archives. - No DB storage of the logs; space was too expensive and the Oracle database we had couldn't have kept up. It was already heavily burdened with a completely separate usage statistics system that fed into user-facing reporting and billing, which had a much higher event rate, about 100x higher, than the http logs. - We had unique tokens, but they identified a particular user session that tied together all of the user's http requests from login to logoff/abandonment, and which also tied into the Oracle-based statistics for that user, that user's organization, and the customer responsible for the user (often multi-organization). My reports had breakdowns for individual user experiences, session-level metrics, and user type/organization/customer/region/etc metrics. - I don't recall how long the analysis took; it was between half an hour to two hours I think. A lot of that time was spent on disk I/O reading the logs. I had optimized the parsing, analysis, and results recording about as much as I could. - This stuff was written in Perl, and ran on Solaris servers from that time era... probably not a lot more powerful than a handful of smartphones today, though they did have lots of cpus. I don't think traffic has grown much since I left the company (we had pretty full market penetration already) so it's likely those servers haven't been upgraded.

dvanduzer 13y ago

Had you tried Nagios and Puppet/Chef when you started developing these? The logging tool is the only one I'm not sure about, if you're parsing 1200 events a second. I'm not familiar enough with Orion to understand why it was insufficient. Would you say these in-house tools are primarily about integrating / presenting the data, or are there custom parts doing more heavy lifting too?

KyleBrandt 13y ago
We use Puppet a lot and are generally quite happy. We have recently started leveraging Hiera which is addressing our main issue we had with Puppet: Reusability problems in the code since Modules (code) and our data were not easily separated. A lot of these tools are about integrating / presenting but that isn't entirely the case. Status does its own polling of things like Redis and SQL. Realog parses the data, structures it in Redis etc, and the patching dashboard can kick of updates.
- dvanduzer 13y ago
  Status handles the scheduling of the polling, or the actual polling, or both? One thing Nagios handles well, although it isn't exactly well polished, is distribution, scheduling, and aggregation of the polling. Also, anecdotally, "nobody" seems to know how easy it is to do simple-intermediate monitoring of MS-SQL in Nagios. I happen to be using this, at the moment: https://github.com/scot0357/check_mssql_collection https://github.com/scot0357/check_mssql_collection edit: And thank you for the concise explanation of Hiera. I had entirely ignored it as just another add-on as Puppet "goes enterprise"
stevenjmurawski 13y ago
We tried Nagios a while back, before going to Orion. Nagios has some great structural ideas, but fell down in other areas (don't know all of them, that was before I came on board). We use Puppet to manage our Linux infrastructure and are testing Desired State Configuration for our Windows systems. Puppet and DSC solve a different problem than monitoring. Our tools span the gamut of aggregating and presenting data, to doing "heavy lifting" of things like installing patches, managing our load balancers, and removing bad query plans from our database servers. Our in-house tooling fills in gaps where existing tooling wasn't responsive enough or made it difficult to deal with certain edge cases. General purpose tools like Orion satisfy 80% of our use cases, but we are fanatical about performance and functionality so we want to fill in that additional 20%. In fact, the majority of our Orion monitors are custom script monitors, which we have to create ourselves as it is. If what we do can work for others (I've worked in several environments with Orion and had the same issues in each environment), that's a bonus. We've found we are building a significant number of these projects and that's why we are looking for a dedicated developer for our team.
- dvanduzer 13y ago
  I'll have to look at the overlap between Puppet's Windows tools and DSC. These are definitely distinct from monitoring, but monitoring configuration should be populated from the same configuration store as Puppet. (Sometimes Puppet is the configuration store.) I've never evaluated Orion in particular, but it's slightly puzzling if you're creating a lot of custom monitoring scripts. In the low-touch Nagios deployments I've seen, this is often because someone didn't understand good places to use macros, and centralize more of the parameters.
  - jacques_chester 13y ago
    The problem is due to history. Configuration systems have historically looked at config as bits-on-a-disk. Supervisor systems look at bits-in-memory. And they emerged and evolved independently. So there's pain points and impedance mismatches regardless of which one you start with. What's needed is a system that sees that configuration and supervision are the same problem: you have a directed graph of what a system can look like, plus a compare-and-repair mechanism to drag the system to that state frequently. I've personally looked at Chef, Puppet and Cfengine, none of which really does all of them the way I would like. http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/ http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...

berkay 13y ago

"We don't really like the idea of cloud hosted monitoring" Can you elaborate on the reasons?

DougWebb 13y ago
I'll bet one of the reasons is the amount of data. At a previous employer I built a system similar to this which produced nightly, weekly, monthly, and annual reports of weblog analysis for an app that had 6 million+ http requests per day. It was tough enough to consolidate those logs across the load-balanced servers in a single data-center. We never consolidated across data-centers (separate reports for each instead) and I doubt we could have shipped all of that data to a cloud service in a reasonable amount of time. BTW, we made heavy use of setting and logging http headers too. One trick I liked was capturing performance timing metrics as a request was processed and stuffing it into a response header as the response went out. We then logged the response headers, which gave us the ability to report on the performance metrics. We also had a debug mode in the app on the browser side so we could see the performance metrics from the headers there too.
- dvanduzer 13y ago
  When was this? ~70 events per second doesn't sound like much to capture and aggregate. How much of this parsing did you need to perform in real time? Creating a unique token to pair requests/responses shouldn't add much overhead at all.
  - DougWebb 13y ago
    Development started around 2000, and stabilized around 2008. As far as I know the reporting scripts are still being run every day. During this period we had purchased a 1TB storage rack from EMC for a million dollars, to give you some perspective on the differences between then and now. - No real-time parsing; it's all nightly batch processing after devops rotates the Apache server logs to a storage volume. The logs sit there for a while then get compressed and moved to offline tape archives. - No DB storage of the logs; space was too expensive and the Oracle database we had couldn't have kept up. It was already heavily burdened with a completely separate usage statistics system that fed into user-facing reporting and billing, which had a much higher event rate, about 100x higher, than the http logs. - We had unique tokens, but they identified a particular user session that tied together all of the user's http requests from login to logoff/abandonment, and which also tied into the Oracle-based statistics for that user, that user's organization, and the customer responsible for the user (often multi-organization). My reports had breakdowns for individual user experiences, session-level metrics, and user type/organization/customer/region/etc metrics. - I don't recall how long the analysis took; it was between half an hour to two hours I think. A lot of that time was spent on disk I/O reading the logs. I had optimized the parsing, analysis, and results recording about as much as I could. - This stuff was written in Perl, and ran on Solaris servers from that time era... probably not a lot more powerful than a handful of smartphones today, though they did have lots of cpus. I don't think traffic has grown much since I left the company (we had pretty full market penetration already) so it's likely those servers haven't been upgraded.