You might look into https://openobserve.ai/ - you can self host it and it's a single binary that ingests logs/metrics/traces. I've found it useful for my side projects.
Look into https://logdy.dev . I've played around with it a little bit, but really putting some work into learning it and integrating it with OTEL traces is my next side project.
Another alternative is https://openobserve.ai/ . It needs to run as a daemon to ingest logs (instead of opening a file), but it has a really nice UI.
Logdy author here, thanks for calling out the project! Kubetail is probably best fit for k8s while Logdy is leveraging more unix-like philosophy of being a self contained tool you can tailor to your needs whether that's tailing files, pumping it through TCP socket or REST API.
I have plans to include a sqlite storage so Logdy could be used in environments where permanent storage is needed
I’ve tried it, but it didn’t seem to have enough structure log support, so I gave up. I just want a way to say “this is a jsonl stream” and have it do the right thing, which is parse out the json paths of each line, and let me filter by those, or add columns for those to the viewer table. It’s not trivial to do this, but that’s exactly why it needs to be done.
Thx. For one API in my company, there is only root and intermediate certificates are present in the jks file but the leaf certificate is not. Would encryption work without a leaf certificate?
In another instance to connect to a server, only the root certificate is present in the trust store. Does it mean encryption can be performed with just the root certificate.
No problem! I also left this response to someone on reddit who said similar:
Nice. I want to write about my experiences someday, but some quick random thoughts about this:
My repository files are huge. i need to break them up. More submodules can work, and defining the inherent methods in a different module than the trait implementation.
I've found the directory structure this advocates, that is,
├── src
│ ├── domain
│ ├── inbound
│ ├── outbound
gets a bit weird when you're splitting things up by feature, because you end up re-doing the same directories inside of all three of the submodules. I want to see if moving to something more like
feels better. Which is of course its own kind of repetition, but I feel like if I'm splitting by feature, having each feature in its own directory with the repetition being the domain/inbound/outbound layer making more sense.
I'm also curious about if coherence will allow me to move this to each feature being its own crate. compile times aren't terrible right now, but as things grow... we'll see.
I love the freedom in a side project to write a thing, then rewrite it, then decide on a new requirement and rewrite it again. No deadlines, no stress, just incrementally experimenting until I'm happy.
At work they rely on me to deliver in a reasonable time, and move on to the next task. Once something is working, it generally isn't changed too much, even to improve it (obviously if it's really important to improve it we make time for that, but that doesn't happen so often)
I think it's nice to be able to write something well, polished and sturdy. Something better than at work. higher ideals.
Or, to write something that is house of cards nonsense that would never fly at work but does something fun. You don't have to explain. Sometimes not having to explain is the BEST.
Sounds neat, but please make testing first class - it should be easy to run functions locally, or to have the same code "infrastructure" run in dev/test/prod environments, etc
I'm writing bigger CLIs with it now and I want to tab through their subcommands and flags, as well as allow customization - suggest values for the current flag based on previous flags' values.
It's been a lot of work (9 months of quite limited side project time)- I had to rearchitect significant parts of the parsing to keep more state around, and learn how I want to approach communication with zsh, but I just need to add some tests and an option or two more and it'll be good enough for most CLIs I wrote.
Oddly enough, I'm procrastinating actually finishing it. I've really enjoyed the "grind" for this feature, and I'm also taking the time to clean up the API if I think of better versions. Being able to noodle around with no pressure (except internal) to deliver keeps the joy in programming going for me.
But, after this is done and integrated into my CLIs, I plan to take a left turn and try to add really good OTEL tracing and visualization to my CLIs- I think I can outut OTEL traces to log files and then embed logdy.dev subcommands for really nice searching and visualization.
reply