Email is not getting triggerred from Logstash - ELK stack - email

I want to trigger e-mail from logstash, when a event occurred more then a threshold limit. I have searched and got some suggestion to configure with Mertic, but I m not getting any e-mail. Here is my code below - what wrong I have done here..? please help.
// This is my filter
filter{
if [type] == "agentapp"{
grok { // no issue with this part
...}
date{ // no issue with this part
...}
// I have added this below for threshold
if [message] =~ "Invalid sm_usergroups" {
metrics {
meter => ["Invalid sm_usergroups"]
add_tag => "metric-tag"
}
}
}
}
// This is my output
output{
if "metric-tag" in [tags] and ["Invalid sm_usergroups".rate_15m] > 1 {
email {
..//email code is also working one. checked.
}
}
}

Problem with metric plugin, which wont work properly. We have done it manually, bt counting the threshold and finally sending the mail.

Related

Huawei SMS retriever api is not working and Huawei devices

I am trying to retrieve OTP in Huawei device. but it is not working.
I have created the app in Huawei developer console with all the requirements.
Below is the code i am using to retrieve the sms.
private fun initSmsManager() {
val task = ReadSmsManager.start(this#MainActivity)
task.addOnCompleteListener {
if (task.isSuccessful) {
// The service is enabled successfully. Continue with the process.
Toast.makeText(this, "ReadSms service has been enabled.", Toast.LENGTH_LONG).show()
} else
Toast.makeText(this, "The service failed to be enabled.", Toast.LENGTH_LONG).show()
}
task.addOnSuccessListener(this, OnSuccessListener {
if(task.isSuccessful){
Toast.makeText(this, "ReadSms service has been enabled.", Toast.LENGTH_LONG).show()
myReceiver = MyBroadcastReceiver();
val intentFilter = IntentFilter(READ_SMS_BROADCAST_ACTION)
registerReceiver(myReceiver, intentFilter)
}
})
task.addOnFailureListener(this, OnFailureListener {
Toast.makeText(this,it.message,Toast.LENGTH_SHORT).show();
})
}
Broadcast receiver
class MyBroadcastReceiver : BroadcastReceiver() {
companion object {
val TAG = MyBroadcastReceiver::class.java.simpleName
}
override fun onReceive(context: Context?, intent: Intent?) {
val bundle = intent!!.extras
if (bundle != null) {
val status: Status? = bundle.getParcelable(ReadSmsConstant.EXTRA_STATUS)
if (status?.statusCode == CommonStatusCodes.TIMEOUT) {
// Service has timed out and no SMS message that meets the requirement is read. Service ended.
// doSomethingWhenTimeOut()
} else if (status?.statusCode == CommonStatusCodes.SUCCESS) {
if (bundle.containsKey(ReadSmsConstant.EXTRA_SMS_MESSAGE)) {
// An SMS message that meets the requirement is read. Service ended.
//doSomethingWhenGetMessage(bundle.getString(ReadSmsConstant.EXTRA_SMS_MESSAGE))
bundle.getString(ReadSmsConstant.EXTRA_SMS_MESSAGE)?.let {
Log.d(TAG, it)
val local = Intent()
local.action = "service.to.activity.transfer"
local.putExtra("sms", it)
context!!.sendBroadcast(local)
}
}
}
}
}
}
Any help in this would be beneficial.
Please confirm the following points:
Check whether the broadcast for receiving SMS verification codes is enabled. You can do that by performing breakpoint debugging or recording logs.
Check whether the SMS message format meets the rules for automatically reading SMS messages.
For details,See Docs.
Check whether the hash_value field is correct.
If no error occurs during the preceding check, could you pls provide a complete log trace then i will try to find out what can be wrong about this issue. :)
All code is working fine it works well on debug mode when I build released apk then keystore changed also hash changes for release mode. If you know anything about how to run on release mode , please let us know. Maybe some changes are made in Huawei developer account

openSIPS setup an onreply route if the call is picked up

I'm wondering if is it possible to set a condition for call answered/picked up in an onreply_route
something like this
onreply_route {
if(call picked up) {
xlog("ON AIR");
}
}
There are quite a few ways in which you can achieve this. For your case, I would use the tm module's t_check_status() function:
onreply_route {
if (t_check_status("2[0-9][0-9]")) {
xlog("ON AIR");
}
}
However, note that this will not work if your SIP proxy is stateless (i.e. if you don't use tm at all)! In this case, we would need to access the information in a more low-level way, by reading it straight off the received message using the $rs variable (SIP reply status):
onreply_route {
if ($rs == 200) { # or ($rs =~ "2[0-9][0-9]")
xlog("ON AIR");
}
}

spray.io strange get/delete/detach directives behavior

I have written the following code using spray routing directives:
path("goal" / Segment) { id =>
get {
detach(ec) {
val goal = srv.find(id)
complete(goal)
}
} ~
delete {
detach(ec) {
srv.delete(id)
complete(OK)
}
}
}
The problem is the execution path is strange. First it goes to get->detach->srv.find->complete
then to delete -> detach -> srv.delete -> complete
and then it comes back to get->detach->... and completes there. The issue is srv.delete is executed which is not a desired behavior because I loose data. Can anyone explain me this behavior and tell me how to fix it ?
Thanks in advance.
I don't understand why but it seems that this modification works properly:
path("goal" / Segment) { id =>
get {
detach(ec) {
val goal = srv.find(id)
complete(goal)
}
} ~
delete {
detach(ec) {
complete {
srv.delete(id) // here
OK
}
}
}
}
Examples in the documentation here shows only cases where after detach comes only complete/reject directive. Therefore I suspect it was tested only with these.
I had the same issue, it looks like something related to Spray route DSL, I solved it adding the command in the path:
(get & path("goal" / Segment)) { id =>
detach(ec) {
val goal = srv.find(id)
complete(goal)
}
} ~
(delete & path("goal" / Segment)) { id =>
detach(ec) {
srv.delete(id)
complete(OK)
}
}
It would be nice to see another solution to be honest instead of having to always replicate the path but up to now this was the only thing which worked.

Some of the Actor messages are missing --AKKA FSM

Here is the sample code flow:
class FSMActor{
when(Idle) {
case Event(Start, Uninitialized) =>
case Event(InitMap(inMap), t # EvaluteRuleMap(v, c)) =>
logger.info(s"State = $stateName, Event = Event(_, InitMap(inMap))")
goto(EVALRule) using t.copy(ruleMap = inMap)
}
when(EVALRule) {
case Event(RowMap(m), t # EvaluteRuleMap(v, c)) =>
logger.debug("input row map m " + m)
**if ( <somecondition> ) { // If comment this if-else block, I could see rowMaps being received.
logger.debug(s"Moving to State Trigger x=$x")
goto(TriggerRule) using t.copy(ruleMap = x.get)
} else {
logger.debug(s"staying in EVALRule, x = $x")
stay
}**
}
when(TriggerRule) {
case Event(_, _) => ....
}
}
}
When the control in in "EVALRule" state, It will keep receiving streams maps(RowMap) and based on some computation, it moves to trigger rule.
Unfortunately for some weird reason, some of the incoming RowMaps are not being received at "case Event(RowMap(m), t # EvaluteRuleMap(v, c)) =>" and
If I comment the code bock (bolded in the above code) then I could see all incoming rowmaps being received.
Could anyone let me know why is so? I've been trying to find the cause but couldn't get it to.
Appreciate your help, thanks.
When if ( <somecondition> ) is true, you are moving to the TriggerRule state. In that state you are looking for messages of type EVENT instead of Event (all caps). So the message is not handled by the FSM.
In general, when missing messages in FSM, the best way to debug is to write a whenUnhandled block with a log/print statement to see what messages are not handled by the states you have defined.
There was some issue with message handling in the code itself, we debugged it and fixed the issue, now its working seamlessly.

Passing Data to a Queue Class Using Laravel 4.1 and Beanstalkd

I have never setup up a queueing system before. I decided to give it a shot. It seems the queueing system is working perfectly. However, it doesn't seem the data is being sent correctly. Here is my code.
...
$comment = new Comment(Input::all());
$comment->user_id = $user->id;
$comment->save();
if ($comment->isSaved())
{
$voters = $comment->argument->voters->unique()->toArray();
Queue::push('Queues\NewComment',
[
'comment' => $comment->load('argument', 'user')->toArray(),
'voters' => $voters
]
);
return Response::json(['success' => true, 'comment' => $comment->load('user')->toArray()]);
}
...
The class that handles this looks like this:
class NewComment {
public function fire($job, $data)
{
$comment = $data['comment'];
$voters = $data['voters'];
Log::info($data);
foreach ($voters as $voter)
{
if ($voter['id'] != $comment['user_id'])
{
$mailer = new NewCommentMailer($voter, $comment);
$mailer->send();
}
}
$job->delete();
}
}
This works beautifully on my local server using the synchronous queue driver. However, on my production server, I'm using Beanstalkd. The queue is firing like it is supposed to. However, I'm getting an error like this:
[2013-12-19 10:25:02] production.ERROR: exception 'ErrorException' with message 'Undefined index: voters' in /var/www/mywebsite/app/queues/NewComment.php:10
If I print out the $data variable passed into the NewComment queue handler, I get this:
[2013-12-19 10:28:05] production.INFO: {"comment":{"incrementing":true,"timestamps":true,"exists":true}} [] []
I have no clue why this is happening. Anyone have an idea how to fix this.
So $voters apparently isn't being put into the queue as part of the payload. I'd build the payload array outside of the Queue::push() function, log the contents, and see exactly what is being put in.
I've found if you aren't getting something out that you expect, chances are, it's not being put in like you expect either.
While you are at it, make sure that the beanstalkd system hasn't got old data stuck in it that is incorrect. You could add a timestamp into the payload to help make sure it's the latest data, and arrange to delete or bury any jobs that don't have the appropriate information - checked before you start to process them. Just looking at a count of items in the beanstalkd tubes should make it plain if there are stuck jobs.
I've not done anything with Laravel, but I have written many tasks for other Beanstalkd and SQS-backed systems, and the hard part is when the job fails, and you have to figure out what went wrong, and how to avoid just redoing the same failure over and over again.
What I ended up doing was sticking with simple numbers. I only stored the comment's ID on the queue and then did all the processing in my queue handler class. That was the easiest way to do it.
You will get data as expected in the handler by wrapping the data in an array:
array(
array('comment' => $comment->load('argument', 'user')->toArray(),
'voters' => $voters
)
)