@ -185,7 +185,7 @@ Connected to OnCall (OpenSource, v1.0.32)
I haven't actually set up any monitoring or notifications yet! The main monitor I want to set up is for low disk space on the nodes, as that seems to be the primary issue that I'm running into - but I'll look around for some suggestions of health metrics and share any good configurations that I find. Regarding notifications, I managed to get a [Matrix](https://matrix.org/) server running a few weeks back, and have made some decent progress on allowing bots to post to rooms - it would be really cool if I could contribute a Matrix integration to OnCall.
I haven't actually set up any monitoring or notifications yet! The main monitor I want to set up is for low disk space on the nodes, as that seems to be the primary issue that I'm running into - but I'll look around for some suggestions of health metrics and share any good configurations that I find. Regarding notifications, I managed to get a [Matrix](https://matrix.org/) server running a few weeks back, and have made some decent progress on allowing bots to post to rooms - it would be really cool if I could contribute a Matrix integration to OnCall.
I'd also like to put in some alerting for if any CI/CD pipelines are blocked - in fact, what prompted this observability improvement in the first place was experimenting with a CI/CD step that would intentionally block publication of this blog if any pages contained the string [TK](https://en.wikipedia.org/wiki/To_come_(publishing)), and then realising that it wouldn't be great to have a pipeline that could be intentionally blocked without some notification of that fact.
I'd also like to put in some alerting for if any CI/CD pipelines are blocked - in fact, what prompted this observability improvement in the first place was experimenting with a CI/CD step that would intentionally block publication of this blog if any pages contained the string [TK](https://en.wikipedia.org/wiki/To_come_(publishing)), and then realising that it wouldn't be great to have a pipeline that could be intentionally blocked without some notification of that fact. (EDIT: having introduced Telegram notifications to the pipeline, the TK-blocking is now in effect!)
I'd also like to build some iSCSI-based network storage, since I've heard that [hosting databases on NFS can be problematic](https://serverfault.com/a/789110).
I'd also like to build some iSCSI-based network storage, since I've heard that [hosting databases on NFS can be problematic](https://serverfault.com/a/789110).
@ -16,12 +16,6 @@ One use of this is as a "placeholder", when you know _roughly_ what will go in a
In the traditional publishing world, an Editor would be responsible for the final pass over the work to make sure all TKs have been caught before sending the content out to readers. In the thrilling world of the future where we have taught sand to think by blasting it with lightning, we can automate that process! Look at the changes to `.drone.yml` in the commit that introduced this blog post to see how.
In the traditional publishing world, an Editor would be responsible for the final pass over the work to make sure all TKs have been caught before sending the content out to readers. In the thrilling world of the future where we have taught sand to think by blasting it with lightning, we can automate that process! Look at the changes to `.drone.yml` in the commit that introduced this blog post to see how.
## What about alerting?
Watch this space. I want the original commit to _only_ include the `.drone.yml` update and minimal blog post, to check it works. I'll post a follow-up with description of alerting (via Matrix) next.
If you're seeing this, then congratulations, you caught the blog post before it was meant to be published. But wait...this whole blog post was about how we'd now made that impossible, right? That's right!
## Wait, but...this blog contains the characters TK?
## Wait, but...this blog contains the characters TK?