For the vim/nvim fans out there, I try my best to add "vim-style" key bindings for navigating between panes, so that e.g. ctrl-h, ctrl-j, ctrl-k, and ctrl-l can be used to move around qukcly. My dotfiles are here:

https://github.com/jay-khatri/dotfiles/blob/main/.tmux.conf

Comments URL: https://news.ycombinator.com/item?id=47607843

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=40355875

Points: 131

# Comments: 25

Definitely something we're thinking of. If you have any particular requirements, we're all ears.

Comments URL: https://news.ycombinator.com/item?id=39229935

Points: 29

# Comments: 2

Today we’re excited to be sharing a performance tool we’ve been working on, which helps you inspect the latency of code execution from the client to the server. As engineers at past startups, we often had to debug slow queries, poor load times, inconsistent errors, etc... While tools like Jaegar [2] helped us inspect server-side performance, we had no way to tie user events to the traces we were inspecting. In other words, although we had an idea of what API route was slow, there wasn’t much visibility into the actual bottleneck.

This is where our performance product comes in: we’re rethinking a tracing/performance tool that focuses on bridging the gap between the client and server.

What’s unique about our approach is that we lean heavily into creating traces from the frontend. For example, if you’re using our Next.js SDK, we automatically connect browser HTTP requests with server-side code execution, all from the perspective of a user. We find this much more powerful because you can understand what part of your frontend codebase causes a given trace to occur. There’s an example here [3].

From an instrumentation perspective, we’ve built our SDKs on-top of OTel, so you can create custom spans to expand highlight-created traces in server routes that will transparently roll up into the flame graph you see in our UI. You can also send us raw OTel traces and manually set up the client-server connection if you want. [4] Here’s an example of what a trace looks like with a database integration using our Golang GORM SDK, triggered by a frontend GraphQL query [5] [6].

In terms of how it's built, we continue to rely heavily on ClickHouse as our time-series storage engine. Given that traces require that we also query based on an ID for specific groups of spans (more akin to an OLTP db), we’ve leveraged the power of CH materialized views to make these operations efficient (described here [7]).

To try it out, you can spin up the project with our self hosted docs [8] or use our cloud offering at app.highlight.io. The entire stack runs in docker via a compose file, including an OpenTelemetry collector for data ingestion. You’ll need to point your SDK to export data to it by setting the relevant OTLP endpoint configuration (ie. environment variable OTEL_EXPORTER_OTLP_LOGS_ENDPOINT [9]).

Overall, we’d really appreciate feedback on what we’re building here. We’re also all ears if anyone has opinions on what they’d like to see in a product like this!

[1] https://github.com/highlight/highlight/blob/main/LICENSE

[2] https://www.jaegertracing.io

[3] https://app.highlight.io/1383/sessions/COu90Th4Qc3PVYTXbx9Xe...

[4] https://www.highlight.io/docs/getting-started/native-opentel...

[5] https://static.highlight.io/assets/docs/gorm.png

[6] https://github.com/highlight/highlight/blob/1fc9487a676409f1...

[7] https://highlight.io/blog/clickhouse-materialized-views

[8] https://www.highlight.io/docs/getting-started/self-host/self...

[9] https://opentelemetry.io/docs/concepts/sdk-configuration/otl...

Comments URL: https://news.ycombinator.com/item?id=39217000

Points: 135

# Comments: 32

Comments URL: https://news.ycombinator.com/item?id=39195134

Points: 1

# Comments: 0

1. We get OSS contributors incentivized to work on the features that we want to prioritize.

2. It acts as a great hiring funnel.

Congrats on the launch.