We use new relic for our http based web servers. I was looking for a similar tool for thrift based servers (binary protocol on tcp) where i can monitor the traffic, performance, crashes etc. Not necessarily as detailed as new relic. How do people in general monitor thrift on production. Its not just about if the server is up or not, i am talking more about all the other metrics like response time, throughput, crashes etc.
Related
i am using nodejs as my server with express. I am logging all my request and response on server. Is there any package available to read my logs and generate graphical report like how many requests we got and how many succeeded. What was the request received and responded. Is there a package which can track all these details for me?
It sounds like you're trying to get some performance metrics about your application which is great. There are many different ways you can go with this, here are a few suggestions for you to weigh up.
Non-real-time performance metrics
If you don't care about seeing the services real-time metrics you might want to create something to process them into a CSV and use something like excel or google sheets to generate graphs from them. If you need something immedietely and don't need to respond to things "in the moment" when a dip happens then this is a good quick and dirty solution.
Real-time performance metrics using SaaS software
If you want the metrics but don't want to host the systems yourself you might want to checkout services such as DataDog. They provide dashboards and graphs as a service. You can use something like statsd to get metrics into DataDog, or use their own integrations. They have a lot of integrations with cloud providers like AWS, GCP, and Azure for machine metrics (CPU etc). They also have packages for inteacting with your application itself such such as their ExpressJS package.
Real-time performance metrics using self-hosted solutions
I've often used a self-hosted approach as I find the pricing often scales a bit better. The setup is fairly simple.
Use a statsd package for all system components (nginx, nodejs, postgres, etc) to publish metrics to the statsd daemon.
The statsd daemon self-hosted somewhere (maybe a proxy cluster if you're working on large applications).
Self-hosted Graphite to consume metrics from the statsd daemon. Graphite is a software package designed for aggregating metrics and has an API for producing static graph images.
Self-hosted Grafana that pulls metrics from graphite. Grafana is a real-time dashboarding software. It allows you to create multiple dashboards that hook into various data sources such as Graphite or other time series data stores.
The self-hosting route can take a day to setup but it does mean you don't increase your costs per-host. It's also easy to put behind internal networks if that's a requirement for your organisation.
Personally, I would recommend either real-time performance metrics approaches. If your application is small and doesn't have many hosts then services like DataDog could be useful and cost effective but if you do need to scale up you'll find your costs sky rocketing. At that point you might decide to move over to a self-hosted infrastructure.
I want to know how many users can request to web page at same time. Can the server be down if 5000 customers come online at same time on website.
This depend on a lot of factors, for example, a simple static HTML webpage can support 5000 clients at same time on a basic server or VPS, but if the website are dynamic and have a lot of operations (with database for example) can turn down the website because hardware resources limits.
This question can't be answered with "yes" or "not", you should test your website with stressing tools and monitoring your server load for each client to get the aprox value of simultaneous clients supported.
If you plain to open a website with a lot of simultaneous clients expend some time on apply a good cache system for your dynamic content.
If your server can't support the current trafic you should plain to upgrade server or use more than one with IP load balancer.
There are a lot of things that can decide if you can or not run a website with 5000 clients at same time, infrastructure, application design, code quality, server configuration...
Capacity depends on your app, it's architecture and the Azure resources you'll be using. CBC/Radio-Canada 2015 election night app achieved peaks of over 800K requests per second with 1,300 compute cores.
Canadian Broadcasting Corporation/Radio-Canada leverage Azure for smooth election coverage
Azure App Service Best Practices for Large Scale Applications
I have an application that is generating 3 kind of log files
Transaction log
Server log
Fatal log
and I want to analyse the performance of my server using appdynamics so what kind of data my logs should be generating to generate analytics for server health, performance, throughput, server utilization?
That's the beauty of APM is you don't need to deal with logging to get performance data. APM tools instrument the applications themselves regardless of what the code does (logging, generating metrics, etc). AppDynamics can collect log data, and provide similar capabilities to what a log analytics tool can do, but it's of less value than the transaction tracing and instrumentation you get. Your application has to be built in a supported language (Java, .NET, PHP, Python, C++, Node.js) and if it's web or mobile based you can also collect client side performance data and unify between both frontend and backend. If you have questions just reach out and I can answer them for you. Good luck!
You basically need the AppDynamics Controller and a AppDynamics Machine-Agent which will be installed on the machine to monitor. In the Machine-Agent configuration you set the URI of the controller and the agent starts to report machine metrics to the controller. Then you can configure alarms, see metrics, create dashboards, etc. I can deliver you more information if you want, but as Jonah Kowall said, take a look at the documentation as well AppDynamics Machine Agent Doc
I have developed an enterprise level application(CRM), And planning to provide it as a SAAS/Hosted Solution.
I am very much worried about the Server & It's Architecture to handle the large traffic. I did some work and reached at, I can use AWS Or Rackspace Claude Service with Load Balancer, RDS, S3.
But still I am not sure it is enough to handle the large traffic or not. I have following questions please provide me some suggestion.
Is there any other good Cluod Service provider than AWS and Rackspace.
How to architect the server(Backup Plan, Highly Available, Data Base Server, Staging etc.)
Please suggest some tool to monitor the server performance.
Server Security.
Tools to calculate the server costing.
Thank You
Is there any other good Cluod Service provider than AWS and Rackspace. - There are options like Google Cloud, HP Cloud, SoftLayer, Azure and many more.
How to architect the server(Backup Plan, Highly Available, Data Base Server, Staging etc.) - Pretty big question to address.
Please suggest some tool to monitor the server performance. -- NewRelic can be one of them.
Server Security. -- Pretty big question to address.
Tools to calculate the server costing. -- https://planforcloud.rightscale.com/ - This would help.
For a notification project, would like to push event notifications out. These are things like login, change in profile, etc., and to be displayed to the appropriate client. I would like to discuss some ideas on putting it together, and get some advice on the best approach.
I noticed here that changes made to a CouchDB can be detected with a _changes stream, picked up by Node, and a process kicks off. I would like to implement something like this (I'm using SQL Server, but an entry point at this level may not be the best solution).
Instead of following the CouchDB example (detecting database-based events, I think this just complicates things, since we're interested in client events), I was thinking that when an event occurs, such as a user login, then a message is sent to the Node server with some event details (RESTful request?). This message is then processed and broadcast to all connected clients; the appropriate client displays notification.
Proposed ecosystem:
.Net 4.0
IIS
IISNode
Socket.IO
Node.JS
SQL Server 2008
This will be built on top of an existing project using the .Net framework (IIS, etc.). Many of the clients' browsers do not support web sockets, so using Socket.IO is a good option (fallback support). However, from what I can see, Socket.IO only still only supports long polling through IISNode (which isn't really a problem).
An option would be to expose the Socket.IO/Node endpoint to all clients, so that client-based notifications can be sent through JS to the Node server, which broadcasts the message. (follows the basic chat-server /client/server examples).
Alternately, an IIS endpoint could be used, but could only support long polling (through Socket.IO). This would offer some additional .Net back-end processing, but may be over-complicating the architecture.
Is there SQL Server-based event notification available for Node?
What would be the best approach?
If I didn't get the terminology ecosystem configuration right, please clarify.
Thanks.
I would recommend you check out SignalR first before considering adding iisnode/node.js to the mix of technologies of your pre-existing ASP.NET application.
Regarding websockets, regardless if you use ASP.NET or node.js (socket.io), you can only use HTTP long polling for low latency notifications, as websockets are not supported by HTTP.SYS/IIS until Windows 8. iisnode does not currently support websockets (even on Windows 8), but such support could be added later.
I did some research lately regarding MSSQL access from node.js. There are a few OSS projects out there, some of them use native, platform-specific extensions, some attempt implementing TDS protocol purely in JavaScript. I am not aware of any that would enable you to access the SQL Notifications functionality. However, the MSSQL team itself is investing in a first class MSSQL driver for node.js, so this is something to keep an eye on going forward (https://github.com/tjanczuk/iisnode/issues/139).
If you plan to use SQL Notifications to support low latency notifications, I would strongly recommend starting with performance benchmarks that simulate the desired level of traffic at the SQL server level. SQL Notifications were meant primarily as a mechanism to help maintain in memory cache consistent with the content of the database, so it may or may not meet the requirements of your notification scenario. At the very minimum these measurements would help you start with a better design.
I would highly recommend using Pusher. That is what we use and it makes it easy to implement as it is a hosted solution. So plugging it and making it work is really easy. It doesn't cost much unless you are going to push a crazy amount of messages through it on a massive scale.