I want an alarm to operate only overnight between 18:00 and 08:00 so I can keep an EC2 instance running all the working day and stop overnight if no-one is using it. Is this possible?
Of course this is possible but you need to write your own script to imitate this scenario, there are ec2-api's available which will help you make this happen.
What you can do:
Write a cron script that will start/stop your instances.
Write a script that will take an input from cloudwatch to take a call on stopping the server if there no request for a n period.
Hope this helps.
You can automate this by creating an EventBridge rule where you specify a cron or schedule expression that runs a Python lambda function on specific timings.
Then, you can use your Lambda function to enable or disable an alarm(s) according to your required schedules.
disable_alarm = client.disable_alarm_actions(AlarmNames=alarm_names)
Here's a good tutorial: https://medium.com/geekculture/terraform-structure-for-enabling-disabling-alarms-in-batches-5c4f165a8db7
Related
I need to notify users of incoming end time of created data. Let's say need to notify the users after 3hrs of created data. But I dont want to run cron job every hour because this will slow down the system.
You can queue a command then add a delay to it.
use Illuminate\Support\Facades\Artisan;
Artisan::queue('your:command')->delay(60 * 60 * 3);
I haven't tried to delay a queue for hours. That's why I think a scheduled task is more reliable as you know the time when it runs.
Laravel has a Task Scheduler pretty efficient to work with cron.
You only have to configure it once to run once a minute and Laravel does the rest for checking when it needs to run.
The syntax is pretty simple and you find all available configurations on your codebase.
https://laravel.com/docs/9.x/scheduling
This hardly slows down the system since Laravel only runs the necessary.
I am given the following problem:
There are two shifts. One shift starts at 12am and the other at 12pm.
At the beginning of each shift, generate some tasks (details not important).
Ordinarily, this is a trivial problem that can be solved with crontab. However, my company is running on Heroku and the Heroku Scheduler has the following interesting properties:
It can only run every 10 mins, hour or daily,
You cannot time when the scheduler will actually start. If you scheduler is running every 10 mins, all you can expect is that it will run between 4:00am to 4:10am.
It is possible that the scheduler encounters some error and crash. When this happens, the scheduler will restart immediately. As an example, if the scheduler crashed at 4:00 while it was running, it might run again at 4:01.
Is it possible to implement a cronjob that:
executes once only once after 12am and 12pm
without needing a database to track its execution time?
One way I can think of doing this would be to have some cron server (not on Heroku) which runs a script at 12am and 12pm.
The script invoked by the cron could use the Heroku Platform API to spin up a one-off dyno in your Heroku app (using the Dyno Create endpoint).
This method satisfies your requirements of executing only once at 12am and at 12pm, WITHOUT using a DB to track execution times.
The drawback of this method is that it is not a "pure Heroku" solution, and requires you to maintain some "external" server to trigger your cron jobs.
If you don't like the ideas of maintaining your own cron server for that, you could use some cloud solution to schedule your script. For example, I would imagine you could do this for free using AWS Lambda with Scheduled Events.
In this case, you would schedule your lambda function to run each day at 12am and 12pm, and your lambda function would spin up your Heroku one off dyno.
Of course if you would be willing to add some form of DB to your Heroku app, you could easily create a "pure Heroku" solution.
I need a better way to use my alerting code.Right now I have a code that check for space free on aws ecs and sends a simple notification to slack if space is less than 5gb using slack api.I used this code in jenkins and setup a periodic schedule to run every 15 min.But once the notification is triggered I wanted it to stop the check for 4 hours so, it won't fill the slack channel with messages .So, i used sleep 14400 after condition is triggered.But this leaves an executor of jenkins waiting.Is there a better way to do this?
If you really want a better way, you should use better tools. there are many tools (some free) out there, that can monitor something in a stateful manner (for example, using a daemon).
Writing to log (or slack channel) in this context of using Jenkins is sort of stateless, for example you cannot check whether an alarm is currently triggered or not.
Since you cannot check if an alarm is already triggered - using jenkins with the logic you requested in your question ('snooze feature') can be very ugly.
In general I would recommend using Conditional BuildStep to trigger a step if a condition is met (i.e. if alarm not already triggered), but since there is no way for you to poll this information, or achieve this with Jenkins without the solution being 'hackish' like creating a file to indicate alert is on, and deleting it from another job if it was created more than 4 hrs ago - I would suggest looking at tools more suitable for the job.
I have a Laravel application where the Application servers are behind a Load Balancer. On these Application servers, I have cron jobs running, some of which should only be run once (or run on one instance).
I did some research and found that people seem to favor a lock-system, where you keep all the cron jobs active on each application box, and when one goes to process a job, you create some sort of lock so the others know not to process the same job.
I was wondering if anyone had more details on this procedure in regards to AWS, or if there's a better solution for this problem?
You can build distributed locking mechanisms on AWS using DynamoDB with strongly consistent reads. You can also do something similar using Redis (ElastiCache).
Alternatively, you could use Lambda scheduled events to send a request to your load balancer on a cron schedule. Since only one back-end server would receive the request that server could execute the cron job.
These solutions tend to break when your autoscaling group experiences a scale-in event and the server processing the task gets deleted. I prefer to have a small server, like a t2.nano, that isn't part of the cluster and schedule cron jobs on that.
Check out this package for Laravel implementation of the lock system (DB implementation):
https://packagist.org/packages/jdavidbakr/multi-server-event
Also, this pull request solves this problem using the lock system (cache implementation):
https://github.com/laravel/framework/pull/10965
If you need to run stuff only once globally (so not once on every server) and 'lock' the thing that needs to be run, I highly recommend using AWS SQS because it offers exactly that: run a cron to fetch a ticket. If you get one, parse it. Otherwise, do nothing. So all crons are active on all machines, but tickets are 'in flight' when some machine requests a ticket and that specific ticket cannot be requested by another machine.
Is it possible to schedule a job to run at a certain time in Parse? For example, I have a calendar app and I want to remind users they have something on in say 10 minutes.
Yes. It is called "Background Jobs" and is a part of Cloud Code.
See guide here: https://parse.com/docs/cloudcode/guide#cloud-code-advanced-background-jobs