We have three health states in SCOM - Healthy, Warning and Critical. Is it possible to add a new custom health state? I tried by editing the System.Health.Library but failed. Is it possible?
Unfortunately there is no other answer except "No. It's impossible.". SCOM has three states maximum hardcoded in a lot of places and it doesn't allow you to have 4 states or more. It's really weird because 4+ states can bring us a lot of interesting and valuable scenarios (especially for ITSM integration), but it is what it is.
I recommend you think how you can break your monitor down to 2 or more monitors to have reasonable and clear 2 or 3-state monitors. In major cases it's possible. If you can give me more details about your case - I'll be glad to help you with design.
Good luck!
Roman.
Related
I'm new to LoRaWAN. I want to set up a new gateway in my country (Algeria North Africa) since it has no gateways yet. I'm having some difficulties concerning finding the appropriate frequency and some similar problems. On the lora alliance website, I found that the suitable frequency for my region is 915MHz but when you start a new setup in thethingnetwork gateway, there is no router or frequency for my region?
How to deal with that before buying a gateway?
And for those who are from Morocco, Tunisia, Egypt, and other countries, how did you pick the suitable frequency?
Here are some images for context:
First: I've never set up a gateway so I might miss some details.
It seems to me that you know almost everything already. What I can understand with my broken french is that you should indeed be using 915MHz as the frequency as the other, 868MHz, isn't allowed in Algeria for use.
It is really sad seeing TheThingsNetwork completely forgets a continent but my solution would be to register it as if you are in the US. Because the frequency (and I'm guessing also the power limit) is equal.
And about your question for the router selection: I would suggest picking ttn-router-eu. I don't know what internet cables connect to Algeria but I'm guessing that the closest is probably a link to Europe and thus the lowest latency router would be Europe. In the grand scheme of things it probably doesn't matter much though.
Maybe you could also raise these issues on the thingsnetwork forum as the frequency/region issue might just be that no one has put in the time/effort to add it to the options. For the router, it might even be possible to start running an application server/router for the ThingsNetwork so you can serve your region, but this is speculation on my part.
Frequency Plans by Country: Algeria AS923_3
I'm trying to get PHPList 3.3.1 to process email bounces and to "unconfirm" or delete users based on email bounces to them. I have the following settings in my PHPList config file:
define ("MANUALLY_PROCESS_BOUNCES",1);
define('USE_ADVANCED_BOUNCEHANDLING',0);
$bounce_unsubscribe_threshold = 2;
I have "Processed Bounces" and PHPList dutifully reads the bounced emails, adds them to the database, and deletes the emails.
However, it doesn't seem to mark users as unsubscribed, even after 2 bounces.
Do I need to add advanced bounce rules? If so, can you provide me with a good basic list of rules to use?
I did try the "Generate Bounce Rules" option and it created 1100 rules (yes, one thousand one hundred rules) - yikes! Seems like there should be something like 5 or 10 rules that would cover most bounces.
Little help?
This is still a relatively undocumented part of phplist. We have a sophisticated list of regex expressions we use but currently not public.
I suggest you start here: PHPList Bounce Rules? to find expressions to track the kind of phrases you want to capture and also the doc itself includes some starting rules: https://www.phplist.org/manual/ch040_bounce-management.xhtml
What is not so documented, or I haven't found at least, is the differences between some of the actions you have available but with a bit of work and time you can fine tune based on your traffic and more important... your customers MTAs.
Further to this questions I started a thread on PHPlists forum than might be of help:
https://discuss.phplist.org/t/please-help-clarifying-advance-bounce-processing/4077/4
if you're still having difficulty with the rules. Be sure they are ACTIVE and not in the CANDIDATE section. Sometimes, with so many created rules the system won't let you just tag them all and change to ACTIVE as it freezes.
You can always go to your phplist database and use the following:
UPDATE `TABLEPREFIX_bounceregex` SET `status` = 'active'
Where TABLEPREFIX should be the same as yours. Hope it helps so many years later.
Consider, as well, installing the Housekeeping plugin ยป https://resources.phplist.com/plugin/housekeeping
I just started using owasp rules and got tons of false positives. Example someone in the description field has written:
"we are going to select some users tomorrow for our job platform."
This is detected as sql injection attack (id 950007). Well it is not. It is valid comment. I have tons of this kind false positives.
First I have set up SecRuleEngine DetectionOnly to gather information.
Then I started using "SecRuleUpdateTargetById 950007 !ARGS:desc" or "SecRuleRemoveById 950007" and I already spend a day for this. modsec_audit.log is alreay > 100MB of size.
I am interested from your experience, how long do you fine tune it (roughly). After you turn it on, do you still get false positives and how do you manage to add white lists on time (do you analyze the logs daily) ?
I need this info to tell by boss the estimation for this task. It seems that will be long lasting.
Totally depends on your site, your technology and your test infrastructure. The OWASP CRS is very noisy by default and does require a LOT of tweaking. Incidentally there is some work going on this and next version might have a normal and a paranoid mode, to hopefully reduce false positives.
To give an example I look after a reasonably sized site with a mixture of static pages and a number of apps written in wide variety of technologies (legacy code - urgh!) and a fair amount of visitors.
Luckily I had a nightly regression run in our preproduction environment with good coverage, so that was my first port of call. I released ModSecurity there after some initial testing, in DetectionOnly mode and tweaked it over a month maybe until I'd addressed all of the issues and was comfortable moving to prod. This wasn't a full month of continuous work of course but 30-60 mins on most days to check the previous nights run, tweak the rules appropriately and set it up for next night's run (damn cookies with their random strings!).
Next up I did the same in production, and pretty much immediately ran into issues with free text feedback fields like you have (of course I didn't see most of these in regression runs). That took a lot of tweaking (had to turn off a lot of SQL Injection rules for those fields). I also got a lot of insight how many bots and scripts run against our site! Most were harmless or Wordpress exploit attempts (luckily I don't run Wordpress), so no real risk to my site, but still an eye opener. I monitored the logs hourly initially (paranoid!), then daily, and then weekly.
I would say from memory that it took another 3 months or so until I was fully comfortable turning it on fully and checked it a lot over the next few days. Luckily all hard work paid off and very few false positives.
Since then it's been fairly stable and very few false alerts - mostly dues to bad data (e.g. email##example.com entered as an email address for a field which didn't validate email addresses properly) and I often left those place and fixed the field validation instead.
Some of the common issues and rules I had to tweak are given here: Modsecurity: Excessive false positives (note you may not need or want to turn off all these rules in your site).
We have Splunk installed on our web servers (basically a tool which sucks up log files and can then be searched or automatically alert or report on issues). So set up a few alerts for when the more troublesome, free text fields fields caused a ModSecurity block (have corrected one or two more false positives there), and also on volume (so we get an alert when a threshold passed and could see we were under a sustained attack - happens few times a year) and weekly/monthly reporting.
So a good 4-5 months to implement from scratch end to end with maybe 30-40 man days work over that time. But it was a very complicated site and I had no prior ModSecurity/WAF experience. On plus side learned a lot about web technologies, ModSecurity and got regexpr-blindness from staring at some of the rules! :-)
This is a bit of an open ended question, but I'm looking for an open ended answer. I'm looking for a resource that can help explain how to benchmark different systems, but more importantly how to analyze the data and make intelligent choices based on the results.
In my specific case, I have a 4 server setup that includes mongo that serves as the backend for an iOS game. All servers are running Ubuntu 11.10. I've read numerous articles that make suggestions like "if CPU utilization is high, make this change." As a new-comer to backend architecture, I have no concept of what "high CPU utilization" is.
I am using Mongo's monitoring service (MMS), and I am gathering some information about it, but I don't know how to make choices or identify bottlenecks. Other servers serve requests from the game client to mongo and back, but I'm not quite sure how I should be benchmarking or logging important information from them. I'm also using Amazon's EC2 to host all of my instances, which also provides some information.
So, some questions:
What statistics are important to log on a backend setup? (CPU, RAM, etc)
What is a good way to monitor those statistics?
How do I analyze the statistics? (RAM usage is high/read requests are low, etc)
What tips should I know before trying to create a stress-test or benchmarking script for my architecture?
Again, if there is a resource that answers many of these questions, I don't need an explanation here, I was just unable to find one on my own.
If more details regarding my setup are helpful, I can provide those as well.
Thanks!
I like to think of performance testing as a mini-project that is undertaken because there is a real-world need. Start with the problem to be solved: is the concern that users will have a poor gaming experience if the response time is too slow? Or is the concern that too much money will be spent on unnecessary server hardware?
In short, what is driving the need for the performance testing? This exercise is sometimes called "establishing the problem to be solved." It is about the goal to be achieved-- because if there is not goal, why go through all the work of testing the performance? Establishing the problem to be solved will eventually drive what to measure and how to measure it.
After the problem is established, a next set is to write down what questions have to be answered to know when the goal is met. For example, if the goal is to ensure the response times are low enough to provide a good gaming experience, some questions that come to mind are:
What is the maximum response time before the gaming experience becomes unacceptably bad?
What is the maximum response time that is indistinguishable from zero? That is, if 200 ms response time feels the same to a user as a 1 ms response time, then the lower bound for response time is 200 ms.
What client hardware must be considered? For example, if the game only runs on iOS 5 devices, then testing an original iPhone is not necessary because the original iPhone cannot run iOS 5.
These are just a few question I came up with as examples. A full, thoughtful list might look a lot different.
After writing down the questions, the next step is decide what metrics will provide answers to the questions. You have probably comes across a lot metrics already: response time, transaction per second, RAM usage, CPU utilization, and so on.
After choosing some appropriate metrics, write some test scenarios. These are the plain English descriptions of the tests. For example, a test scenario might involve simulating a certain number of games simultaneously with specific devices or specific versions of iOS for a particular combination of game settings on a particular level of the game.
Once the scenarios are written, consider writing the test scripts for whatever tool is simulating the server work loads. Then run the scripts to establish a baseline for the selected metrics.
After a baseline is established, change parameters and chart the results. For example, if one of the selected metrics is CPU utilization versus the number of of TCP packets entering the server second, make a graph to find out how utilization changes as packets/second goes from 0 to 10,000.
In general, observe what happens to performance as the independent variables of the experiment are adjusted. Use this hard data to answer the questions created earlier in the process.
I did a Google search on "software performance testing methodology" and found a couple of good links:
Check out this white paper Performance Testing Methodology by Johann du Plessis
Have a look at the Methodology section of this Wikipedia article.
My users use the site pretty equally 24/7. Is there a meme for build timing?
International audience, single cluster of servers on eastern time, but gets hit well into the morning, by international clients.
1 db, several web servers, so if no db, simple, whenever.
But when the site has to come down, when would you, as a programmer be least mad to see SO be down for say 15 minutes.
If there's truly no good time from the users' perspective, then I'd suggest doing it when your team has the most time to recover from any build-related disaster.
Here's what I have done and its worked well for me:
Get a site traffic analysis tool
which will graph hourly user load
Select low-point in graph for doing
updates
If you're small, then yeah, find when your lowest usage period is, and do it then (for us personally, usually around 1AM-3AM PST is the lowest dip...but it never drops to 0 of course). Once you start growing to having a larger userbase, if you want people to take you seriously you'll need to design your application such that you can upgrade without downtime. This is not simple, and it often involves having multiple servers.
I've spent ages trying to get our application to this point, the best I've come up with so far is for a couple hours run both the old version and new version at the same time. Users logged in at the time of the switchover stay on the old version, until they log out. Next time they come in they go to the new version. Any users coming on after the switchover get sent straight to the new version. It's still not foolproof, but it's pretty good.
What kind of an application is it? Most sites that I use tend to update around 2AM or 3AM.
Use a second site, and hotswap as needed.
The issue with hot-swapping, is database would still be shared, and breaking changes would bring stand in down as well.
I guess you have to ask your clients.
In any case, there's the wee hours of the morning. If you're talking about a locally available website, I do not think users will mind if they get an "under maintenance" notice at 2 am in their time zone.
Depends on your location: 4AM East Coast/1AM West Coast is typlically the lightest time.
Pick a few times that you'd like to do it and offer them as choices to the decider-types. Whatever you do, put up a "down for routine maintenance" page while you deploy.
Check the time of least usage
Clone/copy/update latest production code to another directory
If there exists any database migrations to be done, perform any that are required, and non conflicting with the old code base
At time of least usage, move symlink to point to latest code
First use an analysis tool to try and determine your typically "light" traffic times. Depending on the site and your location in the world in comparison to most of your users, it could be 4am, it could be 1pm, who knows. Then, once you have a good timeframe nailed down, make sure to have your deployment process as automated as possible, so that it happens quickly to minimize the downtime of your site.