On the path to 1.0 release

[sv2]

The time has come for swagger-states to graduate to 1.0! During past 4+ years the project evolved a lot, we received a lot of attention, contributions and feedback from many people, and hopefully helped many teams on their journey with Node.js microservices.

It's time to take swagger-stats to the next level !

Here I will summarize the key guiding principles and capabilities that will define swagger-stats 1.0.

As always, really looking forward for your feedback, suggestions and proposals !

Expand the depth and scope of monitoring swagger-stats provides. Why limit to API monitoring only ? Swagger-stats will provide insights on ingress and egress API, Databases, GRPC, and much more. The target is to cover end-to-end processing of requests in microservices and across microservices.

Embrace OpenTelemetry - https://opentelemetry.io/. Swagger-stats will leverage OpenTelemetry under the hood with all the instrumentations available. We will use OpenTelemetry Tracing to get insights into requests processing in microservices and provide meaningful and actionable metrics and dashboards.

Support collecting and processing observability data in the deployments with multiple nodes of microservice deployed (i.e. N+1 ) as well as across multiple microservices

Support micoservices developed in many different languages, not only node.js. Thanks to OpenTracing, swagger-stats will be able to collect and process data from any microservice instrumented with OpenTracing. Processing Traces will enable operational insights across entire deployment.

Support Kubernetes. Swagger-stats will provide Helm Chart and will allow easy deployment to K8s.

And of course, swagger-stats will keep enabling instant observability for Node.js microservices. Capability of requiring single package and getting metrics and dashboards instantly in your microservice is the key feature of swagger-stats, which, we believe, is essential, especially during early development stages.

Please share your thoughts, feedback and considerations !

[sv2]

The work on 1.X is currently tracked in this repo: https://github.com/slanatech/swagger-stats-v1

Currently at early alpha stage, and will be changed very frequently. Eventually will be merged to main repo.

[bhupesh-sf]

We have used swagger-stats in our many loopback based applications (which is a framework on top of express) and running successfully in production. For complete monitoring we also used open-telemetry auto instrumentation separately. We always wished if swagger-stats can become the one package which can do everything and we are really happy to see that initiative here.

Being experienced in open-telemetry we would like to contribute in this initiative and would like to have some guidance how can we help here?

Thanks. @sv2

[bhupesh-sf]

@sv2 can you please help me to understand the roadmap here so we can plan and try to contribute to this noble cause?

[sv2]

First of all, many thanks for your feedback and generous offer ! Please see high-level outline of the roadmap in the next comment.
I would be very interested in your feedback and contribution overall, and especially on p.1.1. One of the goals I'd like to achieve there is to simplify overall initialization of tracing for the microserivce by using swagger-stats. Ideally, app developer should be able to import swagger-stats with minimal configuration, and it will initialize open tracing with reasonable defaults and instrumentations (enabling customizations if needed, of course). Would be great to have your feedback & suggestions on this. Thanks!

[sv2]

This is to summarize high-level roadmap for 1.x release. To be updated with issue ##

1. Phase 1. Match current functionality using open telemetry

1.1 Change swagger-stats to use open telemetry
When initializing swagger-stats in the app, it will initialize open telemetry under the hood, and set up itself as span processor, to be able to process all reported spans locally in the app. Ensure proper parameters passed to open telemetry, to enable all the flexibility with instrumentations and reporters various services may need. Expose tracerProvider to allow app to do further customizations
See https://github.com/slanatech/swagger-stats-v1/blob/master/packages/node/src/swsMonitor.js
1.2 Convert current statistics code to use spans to calculate statistics & metrics,
as opposed to custom instrumentation for various frameworks
1.3 Transition all code to typescript
1.4 Refactor UI to vue3 + vite + tailwind, to keep it small and simple
1.4 Implement handling of API and UI using node http - no frameworks to avoid undesired dependencies for the apps.
Listen on separate configurable port.

Outcome of phase 1 will be 1.0-alpha-1 release.

2. Phase 2. Swagger-stats server to support analytics for multiple microservices based on distributed tracing.
Swagger-stats server to be able to receive spans via grpc using open telemetry and Jaeger protocols.
Open telemetry collector can be configured to send spans to swagger-stats sever as an additional receiver.
Swagger-stats will expose Prometheus metrics calculated based on traces from all the services and provide UI with built-in analytics.

3. Phase 3. Kubernetes
Deployment to K8s using Helm chart.
Support multiple deployment modes as well, i.e. standalone server

[bhupesh-sf]

Great @sv2 . Thanks for the initial pointer. Will surely look towards this.