Most popular logging and monitoring stacks like ELK stack or Time series DB-Grafana are designed to be integrated. Can AppDynamics work with other samplers/DBs, in particular Prometheus?
There are integration tools available between influxdb/AppDynamics and grafana/AppDynamics.
https://github.com/Appdynamics/MetricMover
https://grafana.com/plugins/dlopes7-appdynamics-datasource/installation).
There's nothing that integrates between Prometheus and AppDynamics at the moment
I'm not sure there will be one going forward, seeing how they are competing in the same space from different vantage points (Open Source vs Enterprise)
Related
I would like to know the difference between Grafana and PRTG from a functional point of view.
We use PRTG at work and I have to do a proof of concept on Grafana.
Every morning I look at the errors / warnings reported by PRTG but I lack overall visibility. So after some research I saw that PRTG offer to create MAPS (dashboards) but it seems limited to infra / network.
My objective is initially to make an easy correlation between the infrastructure's monitored elements (storage, vmware, switchs, etc...) and PRTG Maps seem to more or less meet the needs. Also I want to do daily/weekly reporting and easily follow the evolution of the infra over the month.
But on the other hand, I would like to be able to offer application dashboards and potentially dedicated to other teams (helpdesk, change manager, etc.)..
Grafana looks more friendly and especially seems to be able to create dashboards on other perimeters.
Can the two tools be complementary or PRTG is ok on its own ?
Thank you.
PRTG allows you to create application dashboards - you are limited only by sensors you have in your system. This means if you create only system level sensors like Ping, CPU, network utilization - then you cannot really say much about your application since you monitor only infrastructure.
PRTG is good in creating Maps in comparison to other monitoring tools and they are now working on improvement of this functionality (see their roadmap). Creating maps specific to teams in your company is possible with PRTG (permissions can be set) and is good idea in general.
To make weekly/daily reports there is possibility to let PRTG send you email with attached PDF related to sensor[s] you choose. Similar functionality has Grafana (cloud/enterprise version)
The difference between PRTG and Grafana as of January 2022 is that PRTG does not allow you to zoom into charts dynamically (meaning with your mouse at specific start/stop date/time range) - its much more "static" in this regard and you as user wish to have this option. If you create application map in PRTG then you can forget any zooming or changing of date on that dashboard - its just not built for it. Its more like "what is status now" dashboard, but never for analysis of issues which happened yesterday which is exactly what you want if something happened during weekend and its Monday.
I see that Grafana has some Machine Learning possibility where PRTG has none - it only shows you similar behavior of sensors but that is good for a cat (at least i never needed it in my 7+ years of using PRTG)
Grafana as far i know it is just a frontend but PRTG is whole monitoring system inclusive frontend so you are not comparing sensor capabilities here - in this PRTG is really very good and they are adding new sensors every month (meaning for new vendors/hardware you have possibility to monitor them with specialised sensors built just for this hardware)
I don't think you can combine Grafana and PRTG - its either or since you have different monitoring engine on background of Grafana.
Hope it answers your questions
I am looking into distribution tracing tools.
Found there two very popular.
OpenTracing - https://opentracing.io/
Zipkin - https://zipkin.io/
What are key differences between them ?
Which one would you recommend ?
Will you recommend other open source distributed tracking tool ?
Getting a handle on the distributed tracing space can be a bit confusing. Here's a quick summary...
Open Source Tracers
There are a number of popular open source tracers, which is where Zipkin sits:
Zipkin
Jaeger
Haystack
Commercial Tracers
There are also a lot of vendors offering commercial monitoring/observability tools which are either centred around or include distributed tracing:
Appdynamics
AWS X-Ray
Azure Application Insights
Datadog
Dynatrace
Google Cloud Trace
Honeycomb
Lightstep
New Relic
SignalFX
(probably 100 more...)
Standardisation Efforts
Alongside all these products are numerous attempts at creating standards around distributed tracing. These typically start by creating a standard API for the trace-recording side of the architecture, and sometimes extend to become prescriptive about the content of traces or even the wire format. This is where OpenTracing fits in. So it is not a tracing solution itself, but an API that can be implemented by the trace recording SDKs of multiple tracers, allowing you to swap between vendors more easily. The most common standards are:
OpenTracing
OpenCensus
OpenTelemetry
Note that the first two in the list have been abandoned, with their contributors joining forces to create the third one together.[1]
[1] https://opensource.googleblog.com/2019/05/opentelemetry-merger-of-opencensus-and.html
MEAN stack and IOT are the current trending hot topics. Can these two be used together? If yes then in what way?
How can these technologies be used together?
Sweta.
By saying MEAN.js you are including things that are not strictly in the IoT terrain. Angular for example has little to do with anything.
On the web front end you need to implement a javascript library like Paho.js that will use the MQTT protocol to connect to a broker and start aggregating messages from connected devices.
Express has little to do as well as you are not exposing a Restful interface but connecting low level through a broker. A good solution in Node.js is Mosca.
Mongo is good for dumping data from devices.
I have written a tutorial using Node.js and iOS so have a look and you might find it interesting.
Mean stack is the combination of the frontent web frameworks like angularjs,emberjs,knockoutjs,backbonejs , javascript's backend server called nodejs and using the mongodb at top. so using these frameworks and library will make a mean stack developer.
IoT pronounced as Internet of things. iot is recently used for connected electronics devices .basically it is a form of running your program inside the electronic chip and mostly trying to connect the devices.making control on devices using the programmed chip. there are separate IDE's are avaialble for developing and testing the programme on embeded chip.
you can use angularjs as a frontend(making your GUI) for your IoT'S application.
Yes, you can.
As a fact is has been done before. And in other frontend frameworks too. Here there is an example for home automation.
You can find even a yeoman generator for such projects here.
[Disclaimer: I work here] Netbeast started managing devices and creating a system of plugins on top
of a MEAN app and RESTful communications. (Now we use a MERN
stack, with react and MQTT over websockets to control networks and
update values in real time.)
To mention other places where you can find examples of current projects using MEAN to run IoT networks I encourage you to join angular, arduino and raspberry communities, as well as taking a tour over producthunt.com, hackster.io and other maker sites such as the previously mentioned Netbeast forum.
Yes you can make an IoT platform with the MEAN stack. Typically the sensors are low cost sensors and are constantly transmitting small amounts of data in MQTT or TCP protocols. With Node.js you can write, servers for such applications very easily.
Mongo is useful if you have unstructured data, which could happen if you work with multiple sensors. If you don't need unstructured data structures, SQL is sufficient.
All the data that you get from devices, finally needs to be consumed via applications. Express and Angular are great platforms to manage web applications.
You can read a little more about IoT platforms in MEAN at http://blog.yatis.io/scalable-iot-platform-mean-stack/
I want to know what is the difference between these two implementations of neo4j. Of-course names of both techniques is self-explanatory,but still what are the main differences?
What factors should be considered in deciding which technique to use in the project?
Pros and cons.
P.S. Sorry if it is a repeat question but I searched and was not able to find any ques which answers my question.
Because the standalone server is built on the embedded server, the general rule of thumb is that the embedded server is more capable and has (obviously) lower latency. Either can operate in High-Availability mode, allow monitoring, and even accept connections from the neo4j-shell. With the server though, you get more functionality out-of-the-box, like remoting, basic visualization, monitoring interface, etc.
The differences are otherwise the practical ones you'd imagine. Choosing a deployment approach is influenced by two things:
Language - embedded mode requires that you're implementing your application with a JVM compatible language. The server supports any language/framework that can send HTTP requests.
Hardware - sharing physical resources between your application and Neo4j can be demanding. Scaling may argue for a dedicated machine to split out the persistence layer. The server obviously has a remote API to support segmenting your application.
It's otherwise difficult to give guidance without a specific usage scenario. Deploying into an existing Service Oriented Architecture? Probably server. Running on an copier machine? Go embedded. From scratch web application? What's the rest of your stack?
What are peoples opinions on jira studio? i.e. using the hosted product for a large company. Especially with hosted source control and reliability of the service?
Is this product up to large scale implementations yet?
I've been using JIRA Studio (hosted) extensively over the last few weeks with a Java project. So far my experience has been resoundingly positive, with the following caveats:
Setting up Elastic Bamboo requires filing a support ticket. While admittedly the process is fully automated and very easy, it can still take a day or two before you can begin setting up your builds;
In my opinion, SVN hosting is limiting. I've been very much looking forward to working with git or Mercurial, but I'm not aware of any plans to add support for those. You can certainly find a separate host for your sources, but you'd be losing on ease of use, out-of-the-box integration with issue tracking and the JIRA dashboard (which I've grown to absolutely love) and will have to sign with a second provider.
I would rate the primary advantages as:
Very low integration cost (compared to e.g. setting up your own Bugzilla+Mediawiki+Hudson setup);
Relatively low TCO, particularly if you have a small staff and no Linux hackers to get you started up;
Very smooth administration and usage experience. I've very rarely had to look in the documentation, and then it was usually clean and informative.