search

taddison / tsqlScheduler

Create and monitor agent jobs & execution from tables
MIT License
3 stars 0 forks source link

Master Log / Aggregator Service #52

Open petervandivier opened 6 years ago

petervandivier commented 6 years ago

In a multi-AG installation, there are times when you want to poll all the jobs. Instead of collecting scripts to dynamically discover scheduler installations (either via local config or asking does a scheduler exist in this DB?), perhaps it's prudent to deploy a per-instance aggregator?

taddison commented 6 years ago

Are there any specific problems you're looking to tackle with this, or is this a building block? A specific problem might be are any of the jobs on this instance failing? - for which an aggregated layer definitely solves this, but there are other solutions (e.g. a script that discovers all DBs and queries them).

In terms of implementation of an aggregation area ('all the logs'), do you want to make that SQL Servers concern, or could it live outside of SQL (if you have a folder full of files that describe environments, that same metadata could drive a script to hoover up those logs and dump them on one server, rather than having to stage locally).

Once the 'get all the logs' bit is solved, I'd ask if SQL is the right home for them vs. Log Analytics/Splunk/etc. The 'hoover up all the logs' still needs to be solved in this scenario.