Is it possible to send metrics from client directly to graphite bypassing server? For this I've defined handler on client and point handler to udp socket with graphite. But it doesn't work.
The client is not configured to make use of handlers. You could do this by having the check itself ship metrics over TCP before exiting, but that is not really a supported approach from Sensu. You're probably better off using something like Telegraf for shipping to Graphite directly from clients.
Due to Sensu's decoupled design, it's not possible to bypass the Sensu Server, as the connections work like so:
sensu-client --> rabbitmq(or whatever you're using for your transport mechanism) --> sensu-server
Vase is correct in that you'll have to use something else to ship metrics to Graphite, or something similar. It's also worth noting that specifying a handler on a client definition will not work. The handler will have to be specified in the check, as handlers are dealt with on the sensu-server side. For a better understanding of the Sensu flow, I'd recommend taking a look at the free training done during the fall: http://youtube.com/playlist?list=PLqLtpBjHqwC-4o7HLtK3MM2V_GdtSh-Dw . If you have any questions after watching that, I'd head over to the Sensu community slack channel at slack.sensu.io.
Related
Creating a user, adding some record to collection in the DB, updating some stuff, etc..
All of these we regularly do with HTTP requests against REST api.
Think about making Event bus as server instead of REST api.
In that method, create user will be an event name: "CreateUser" instead of REST api endpoint: POST /users.
In reflect to any action done in the event bus, it will re-emit a following event telling to any body needed to know about, that the event was done.
If for example someone viewing the vehicles collection and another user just edit one of the columns or add a new vehicle instance, it will be reflected immediately to who views it online.
My question is if there attitudes like I mentioned above, if there some formally names for it, if it a good practice, if you know someone who regularly uses it, a framework or something etc. Does the socket.io server can handle and behave like http server in high workloads?
You can use websockets for this; they provide a bidirectional channel between client and server to send messages across. You will have to catch and parse the messages on each end yourself, as there is no additional protocol on top of them.
They don't hold state, so there is no knowledge of who is looking at what, or who got what. You could send the same update message to all connected clients and leave it to the client to use it or not.
You would have to reprogram your client code and the API endpoints, because it's a different way of doing things, and it can also do server push.
I have no idea about frameworks though, as I always use them without one. Websockets are fast, but server behaviour at high workloads depends on implementation, and I only have experience with the websocket server I wrote myself. I suppose the performance of the socket.io can easily be googled.
I’m trying to build a trading simulator that consists of Broker (client)-Router(acceptor)—Market(client). The documentation is very sparse on QuickFIX/J. I’d like to know in detail:
How messages are handled in general and if the acceptor has any out of the box router table?
I'd like clarification on the toApp, fromApp and toAdmin and fromAdmin methods.
Effectivly, I'd like to communicate between the broker(s) and market(s) via the acceptor(router). I know there is no out of the box solution for tag based communication and so I'd have to implement some protocol for that, but i need a broad understanding of the messaging service first. I've read and looked at the documentation but it seems a bit abstract to me. I'd like to know in plain terms, how the client processes messages to and from the acceptor using the above methods, and vice versa.
Also if there any classes/Objects/methods that are key in message handling and their implementation in plain terms.
Also does quickFiX use blocking, non-blocking or asynchronous sockets?
*ps I've already created 2 clients and 1 acceptor, and this is working perfectly
**I'm language agnostic so any explaination in the other ports of the quickFix library would be helpful
Here is an explanation of the various callbacks: https://github.com/quickfix-j/quickfixj#creating-a-quickfixj-application
Basically you need to implement these methods in your application and can do whatever you want based on the tags that you want.
Sending a message to a specific session is as simple as calling
Session.sendToTarget
See https://github.com/quickfix-j/quickfixj#sending-messages
If you feel that something from the documentation is missing, please open a pull request (preferred) or issue.
QFJ uses the MINA library for communication which under the hood uses Java NIO (non-blocking IO). You are however able to use some sort of blocking via the synchronous write option. See SocketSynchronousWrites configuration option.
I'm willing to use ejabberd / mongooseIm in a microservice network. XMPP should be our chat protocol aside from a REST API network. I want to send messages incoming at the xmpp server downstream to worker services. Has anybody done this or could lead me into the right direction?
My first thoughts are using RabbitMQ for sending the new incoming messages to the workers.
There are basically two choices to giving your workers access to the messages routed by ejabberd / MongooseIM. I'll focus on MongooseIM, since I know it better (DISCLAIMER: I'm in the dev team).
The first is to scan the message archive in an async / polling fashion. The Message Archive Management describes XMPP level protocol for accessing it, but for your use case the important part is message persistence - so just making sure the relevant module (mod_mam) is enabled in server config and the messages will hit the database. The databases supported for MAM are PostgreSQL and Riak, though there was also some work on a Cassandra backend (YMMV). This doesn't require tinkering with the server / in Erlang for as long as there's a DB driver for your language of choice available. Since PR#657 it's possible to store the messages in raw XML or even some custom format if you're willing to write the serialization module.
The second option is to use the server mechanism of hooks and handlers (also available in ejabberd), which can trigger a server action on events like "user sent a message", "user logged in", "user logged out", ... This, however, requires a server side extension written in Erlang. In the simplest case the extension could forward any interesting event (with message content and metadata) via AMQP or just call some external HTTP/REST API - that way the real work is carried out by the workers giving you the freedom with regard to implementation language. This options also doesn't require to enable mod_mam or set up a database for message persistency (which you could still have with a persistent message queue...).
In general, the idea is perfectly feasible.
Generally, the most common XMPP extension use to build messaging systems for machines-to-machines, internet of things, microservices, etc is PubSub, as defined in XEP-0060.
This is a module you can enable in ejabberd. It is API based, so you can even customize the behaviour of that module to your application specific.
Pubsub basically allows to decouple senders and receivers and is especially designed for that use case.
We're running Asterisk version 1.8.4.2 and I'm looking to create a server application that will allow several client programs to check on the "presence" of specific extensions, among other things. I understand that the AMI will allow me to poll this information, however I was hoping there might be a way to give the server an extension and subscribe it to the extensions in question to avoid having to poll the AMI constantly.
It seems like I might have to implement the SIP protocol into my server if BLF were the route I wanted to take. Is there a better and simpler solution that I've managed to overlook in my research?
You could implement these approaches:
AMI event hook and digging in incoming events
Make your application subscribing on notifies on extension status changes via SIP notifies
Make your asterisk publishing extensions status with XMPP
I am using the JMX-RMI agent for message passing. I have a java program which sends a message having a name/id to a set of listener/listeners.Based on the message received by the listeners the client side programs behave accordingly.This piece works fine but I would like to know what kind of fault tolerance is built in into the JMX RMI agent.
If the listener stops accidentally, does JMX restart it or logs the error somewhere,what if the message queue on either side is full. Any documentation which explains the underlying architecture of JMX RMI or the in built fault tolerance mechanism will be appreciated. If it doesn't have any fault tolerance mechanisms, what would be a good way of doing it.
Thanks Much
I am assuming your client side listeners are using the standard javax.management.remote connectors. Without some customization, I would say you can implement some straightforward Fault Detection. For Fault Tolerance you're probably looking at some sort of clustering solution.
There are two layers of connectivity you need to be concerned about:
The MBeanServerConnection itself. In other words, if the whole server side JVM terminates, your client side processes need to know.
While the server JVM and the subsidiary MBeanServerConnection may continue to be available, the "hosted", the listener/client message forwarder service itself may stop/fail/stall.
For #1, the client processes can register a NotificationListener with the JMXConnector using the addConnectionNotificationListener method. Your local connection will then emit JMXConnectionNotifications on all the following events:
A new client connection has been opened.
A client connection has been closed.
A client connection has failed unexpectedly.
A client connection has potentially lost notifications. This notification only appears on the client side.
This way, your clients will know when a connection to the server has been established and lost.
For #2, it's a bit more specific to your application, but perhaps you can adapt a simple pattern like this:
When your listener/forwarder service starts, emit a start-notification. When it stops,emit a stopped-notification. The two categories of listeners that would register for these notifications would be:
The clients, so they know the service has started/stopped.
A server side "watcher" that can listen for a "stop" and restart the service.
Is that more-or-less what you were thinking of ?