I am working on an application that accepts incoming HTTP requests and contains the user's zip code. I would like to track each of the zip codes received using a metric such that it can be reported to Prometheus and graphed inside Grafana. It would not make sense to have a counter for every single zip code but I worry that a Gauge would not be appropriate and Grafana would miss some of the data between Prometheus scrapes. Any suggestions for how I could possibly accomplish this task? We do have logging but we need this information displayed in Grafana.
This is more a use case for logging than metrics given the cardinality.
This is a use case for a label, however Dropwizard doesn't support those. Thus if you're going to do this with Prometheus I'd suggest using the Java client with a Counter with a label for the zip code.
Related
I know that we can use web url to get the metrics.
However, I want to get the data that created by spring-boot-actuator in my code.
I want to program to get the metrics and then publish to other destination in my spring-boot project.
The micormeter-registy-xxxx can not solve my problem.
If you want to publish the data to another destination, you need to implement your own registry. Take a look at other registries to see how to do it.
If you want to push metrics to logs or use the data as string, you can take a look at LogingMeterRegistry and SimpleMeterRegistry#getMetersAsString.
I was wondering if it is possible to collect all metric from Prometheus with Java client?
For example Go metrics, host metrics etc.
If yes, can these metrics be queried like on HTTP api?
Could you please clarify: "instrumenting" usually means exposing metrics from your application's code to a Prometheus endpoint. The question reads that you either want to read metrics from an application, or from a Prometheus instance that has already scraped the metrics.
For this answer I assume that you're running a Prometheus instance that has already scraped the metrics.
If you want to read the most current values that Prometheus has scraped from your applications, you can use Prometheus' federation endpoint via HTTP: you can read all metrics with their current readings in one go, or apply a query. I'm not aware of a Java library to parse the format, but you find the definition here. You could use the same approach to query your applications directly.
If you want to receive a JSON that might be easier to parse, you can use Prometheus's HTTP API.
If you want to receive updates on values as soon as Prometheus queries them, you can hook up to the remote write API. There is already existing integrations, but at first glance there is no Java integration. You could use Kafka as an intermediary. Also, this might be more than you've asked for in this questions.
I'm using Light-4J as microserver, sitting between my clients and a 3rd party API. Everything is setup and working, the clients are able to POST requests and responses are sent in reply.
However I want to know how many requests have been processed since the server started. Since I use Log4j to each successful API call I thought I might be able to read the number of lines in the log file. This works but is not accurate since I discovered that other processes are also writing to the file so the total is skewed.
Is there another way to get the data I require without me having to ensure that my requests have exclusive access to a log file?
light-4j supports metrics that can be pushed to influxdb or pulled by prometheus. You can enable it in your microservice service.yml or handler.yml (if you are using release 1.5.18 or later)
https://www.networknt.com/concern/metrics/
https://www.networknt.com/concern/prometheus/
If you generate the project from light-codegen, then the Influxdb metrics is wired in but disabled. You just need to install an InfluxDB instance and enabled it in your microservice.
Also, if you only need to proxy to your backend service, light-proxy might be the way to go unless you have some business logic in your microservice.
We have configured storm cluster with one nimbus server and three supervisors. Published three topologies which does different calculations as follows
Topology1 : Reads raw data from MongoDB, do some calculations and store back the result
Topology2 : Reads the result of topology1 and do some calculations and publish results to a queue
Topology3 : Consumes output of topology2 from the queue, calls a REST Service, get reply from REST service, update result in MongoDB collection, finally send an email.
As new bee to storm, looking for an expert advice on the following questions
Is there a way to externalize all configurations, for example a config.json, that can be referred by all topologies?
Currently configuration to connect MongoDB, MySql, Mq, REST urls are hard-coded in java file. It is not good practice to customize source files for each customer.
Wanted to log at each stage [Spouts and Bolts], Where to post/store log4j.xml that can be used by cluster?
Is it right to execute blocking call like REST call from a bolt?
Any help would be much appreciated.
Since each topology is just a Java program, simply pass the configuration into the Java Jar, or pass a path to a file. The topology can read the file at startup, and pass any configuration to components as it instantiates them.
Storm uses slf4j out of the box, and it should be easy to use within your topology as such. If you use the default configuration, you should be able to see logs either through the UI, or dumped to disk. If you can't find them, there are a number of guides to help, e.g. http://www.saurabhsaxena.net/how-to-find-storm-worker-log-directory/.
With storm, you have the flexibility to push concurrency out to the component level, and get multiple executors by instantiating multiple bolts. This is likely the simplest approach, and I'd advise you start there, and later introduce the complexity of an executor inside of your topology for asynchronously making HTTP calls.
See http://storm.apache.org/documentation/Understanding-the-parallelism-of-a-Storm-topology.html for the canonical overview of parallelism in storm. Start simple, and then tune as necessary, as with anything.
I have a webapp with an architecture I'm not thrilled with. In particular, I have a servlet that handles a very large file upload (via commons-fileupload), then processes the file, passing it to a service/repository layer.
What has been suggested to me is that I simply have my servlet upload the file, and a service on the backend do the processing. I like the idea, but I have no idea to go about it. I do not know JMS.
Other details:
- App is a GWT app split into the recommended client/server/shared subpackages, using an MVP architecture.
- Currently, I am only running in GWT hosted mode, but am planning to move to Tomcat in the very near future.
I'm perfectly willing to learn whatever I need to in order to get this working (in fact, that's the point of writing the app). I'm not expecting anyone to write code for me, but can someone point me in the right direction to get started?
There are many options for this scenario, but the simplest may be just copying the uploaded file to a known location on the file system, and have a background daemon monitor the location and process when it finds it.
#Jason, there are many ways to solve your problem.
i) Have dump you file data into Database with column type BLOB. and have a DB polling thread(after a particular time period) polls table for newly inserted file .
ii) Have dump file into file system and have a file montioring process.
Benefit of i) over ii) is that DB is centralized and fast resource where as file systems are genrally slow and non-centalized in nature.
So basically servlet would dump either to DB or file system. Now about who will process that dumped file:- a) It could be either montioring process as discussed above or b) you can use JMS which is asynchronous in nature what it means servlet would put a trigger event in queue which will asynchronously trigger new processing thread.
Well don't introduce JMS in your system unnecessarily if you are ok with monitoring process.
This sounds interesting and familiar to me :). We do it in the similar way.
We have our four projects, all four projects includes file upload and file processing (Image/Video/PDF/Docs) etc. So we created a single project to handle all file processing, it is something like below:
All four projects and File processor use Amazon S3/Our File Storage for file storage so file storage is shared among all five projects.
We make request to File Processor providing details in XML via http request which include file-path on S3/Stoarge, aws authentication details, file conversion/processing parameters. File Processor does processing and puts processed files on S3/Storage, constructs XML with processed files details and sends XML via response.
We use Spring Frameowrk and Tomcat.
Since this is foremost a learning exercise, you need to pick an easy to use JMS provider. This discussion suggested FFMQ just one year ago.
Since you are starting with a simple processor, you can keep it simple and use a JMS Queue.
In the simplest form, each message send by the servlet has to correspond to a single job. You can either put the entire payload of the upload in the message, or just send a filename as reference to the content in the message. These are details you can refactor later.
On the processor side, if you are using Java EE, you can use a MessageBean. If you are not, then I would suggest a 3 JVM solution -- one each for Tomcat, the JMS server, and the message processor. This article includes the basics of a message consuming client.