PostgreSQL and multiple-server support brings Dawn to the enterprise
Posted by on 4 February 2011
If your website runs across multiple servers or uses PostgreSQL as its database, Dawn™ can now support your environment! This week we’re excited to release a major update to Dawn. Previously Dawn could only monitor a website if it ran on a single server. You can now use Dawn to monitor websites spread across multiple servers. Likewise, previously Dawn could only monitor websites running on the MySQL database; we have now extended Dawn to support PostgreSQL. In addition to database and multiple server support, we've also improved Dawn alerts and reporting as detailed below.
We're pleased that a wider pool of people using SilverStripe CMS to run critical websites can now enjoy the ease and power of monitoring their websites with Dawn.
Multiple web-server support
Dawn now supports website architectures comprising multiple web-servers, each running PHP and serving pages via SilverStripe CMS. Under this scenario, each server has the Dawn Agent and Logger installed, and the dashboard will show each server as a separate set of concentric rings in the dashboard.
For complex websites, you may want to set up your database on a dedicated machine, separate from your web server. This dedicated machine wasn’t previously able to be monitored with Dawn, as it used to require that the webserver and the database were on the same machine. Now you can split these two functions and use Dawn to make sure everything's working as expected.
PostgreSQL
Dawn can now monitor websites powered by a PostgreSQL database, not just MySQL. PostgreSQL is often chosen over MySQL for websites that deal with huge sets of information, or have geospatial data, or deal with transactions (e.g. online stores). Dawn becomes useful to more sophisticated sites than it used to, now that Dawn supports PostgreSQL databases.
Alerts when your site comes back online
Obviously, Dawn will send you alerts when your site goes down. Now, it will also send you an alert when your site comes back online, letting you know exactly when your visitors can reach your site again.
Disk space usage
Now Dawn can monitor the amount of disk space that is used on your server. As alerts are fully customisable, you can choose to be warned if you’re running out of room.
As well as these features, we've also done some tinkering behind the scenes to make it all run a little faster. For more information about Dawn, read our other blog posts, have a play with the demo, or give our 30 day trial a go!
How to get your Dawn on
Posted by on 12 November 2010
Until now you had to contact us to try out Dawn™ , but now you can do it all yourself. That’s what we’d like to tell you about Dawn this week. So off you go, and sign up now! What, you'd like some more information? Okay, sure.
We've already already told you about some of Dawn's key features, and talked you through the Dawn Demo. We went into detail about how we use Dawn, specifically on the elections2010.org.nz site, and you've heard how Lloyd uses it on the Philadelphia Police Department's website.
The thing is though, that we can talk up Dawn until we're blue in the face, and hopefully you will like the sound of it, but it's possible that you won't truly understand how useful Dawn will be until you try it for yourself. That’s why we're encouraging you to sign up now. There's a free 30 day trial period which will give you access to the full kit and caboodle. Once you start receiving alerts on your own sites, we reckon you’ll be hooked. So let's go through the sign-up process together, shall we?
First, head on over to the plans page. You'll see that the basic plan gives you the free trial.
Click through to the signup page where you can create an account. Yes, at this stage you will be asked for a credit card number, but if you choose not to continue after your 30 day trial, you won't be billed.
Then you can download and install Dawn.
Then you're up and running, yay!
Get your Dawn demo here folks
Posted by on 28 October 2010
We've been talking about Dawn™ for a while now, but really, we'd rather show you it than tell you about it. That's why we've created the Dawn demo. Go ahead, click it open in another tab. I'll wait right here for you.
Okay, so what you're looking at is a live demo of the Dawn application. It shows you exactly what you'd be seeing as a Dawn user if you were to install it on your site - only the sites that we've got it configured to use are the real live sites SilverStripe.org and userhelp.silverstripe.org. You're seeing what we see when we keep an eye on them. We figured that providing a real world scenario rather than something that's fake would be the best way to give you an insight into what you really get with Dawn.
Now, let's unpack what you're looking at in more detail. The Dawn application looks at the different layers that power a website. Starting right in the middle is the overall status of a website. Moving outwards, we find the operating system, then we've got the web server, the database, and finally the SilverStripe layer on the outside. You'll see more information about each of these layers pop up on mouseover, and clicking any of them will take you to more information. The colour of each circle and the length of the line changes according to the severity of any problems.
In the picture above, (which may look different from the live site, as things change all the time), you can see that the SilverStripe layer on SilverStripe.org has some issues. If I was the project manager on this site, I'd know this meant I needed to talk to my developers. The developers are then able to see the exact errors (including stack traces) that SilverStripe reports, which gives them a starting point for debugging.
With Dawn's dashboard, you don't need to be able to code in order to assess the health and state of the site, but if you are a developer, it's very useful for you as well.
While you're playing with the demo, you might want to go into the settings and choose the charts you want to look at. You can also filter to see what issues you want to see, or use the slider on the dashboard to go to previous days, or project the future. Any time you come across an issue, click it for more information.
Because this is the demo version, you won't be able to save your changes, or close issues once you've resolved them. But you should still be able to get a pretty good overview of Dawn.
Of course, your own sites are probably of more interest to you than SilverStripe.org is. That's where our free 30 day trial comes in! To give Dawn a go on your own site, sign up now. Yes, it will ask you for a credit card number, but those details are held separate from SilverStripe Ltd, and we won't charge you anything unless you decide to keep using Dawn past those 30 days. Naturally, we expect that you'll find it indispensable once you get started!
An election day dawns
Posted by on 15 October 2010
On October 9, results for New Zealand's Local Body Elections were announced. The day saw nearly 80 mayors and hundreds of other local representatives democratically elected. As we were responsible for the elections2010.co.nz website, an official source of election results, this was a big day for us. We began publishing results from noon, the deadline for people to cast their vote. We thought there was a good chance it would attract a little extra traffic from that point forward.
As this screenshot (below) from Dawn™ shows, we were right about the increased traffic. In fact, more specifically, the traffic for the 24 hours from noon Saturday to noon Sunday included these statistics:
- Over 15 million hits,
- Almost 1 million page views,
- Over 80,000 visits,
- Over 40GB traffic (notable given it is mostly a text-based website, with few images. All video content is served through Youtube, and not part of this statistic.)
These are big numbers for a site running on one Linux server, especially given content was fetched from databases, and there were constant updates to the website because results for electorates around the country were coming in over a space of several hours.
People wanted to know who was winning around the country, so it was vital that elections2010.co.nz stay up to provide those answers. stuff.co.nz, the most popular news website in the country, was linking to the elections website, and was the single biggest source of traffic. That's why we used Dawn, our website monitoring software, to keep an eye on the site.
"Dawn helped us to ensure that people could get access to the results of the elections as soon as they were published,” says our Head of Development Rainer Spittel.
We knew the CMS was going to be updated constantly over the day as more results came in, and that CMS updates are a much bigger use of CPU than someone visiting the website. The graph from Dawn above shows that the server handled the traffic smoothly from a CPU perspective. The graph shows early morning to midnight for Saturday, the busiest day for the website.
"During peak load, I was using Dawn to compare and monitor present and historical CPU and memory use, and other metrics like page-load times. Dawn presents this information clearly and intuitively, and it means you can make assessments quickly and confidently," adds Rainer.
Despite anticipating heavy traffic, the project team here at SilverStripe didn’t have to stay in the office all Saturday by the servers, because they knew they’d receive SMS alerts from Dawn if there were any issues. We’d also prepared in advance, naturally.
"Dawn allowed us to forecast how much traffic the server could handle. It made it obvious where some pages were slow when we were building the website, and wouldn’t survive the level of traffic we anticipated for election results day. It focussed our attention to webpages needing optimisation, and as a result, we optimised important pages on the website to a level where a single server could handle over 500 page views per second. Dawn validated that we made the right choices, and we met all our targets in terms of performance, robustness and response time,” says Rainer.
The great thing about Dawn is that its simple interface means that less technical people can also use it, such as our Project Manager Diana Hennessy, who says "I was reassured by logging into Dawn during the peak traffic on Saturday afternoon. The system is very intuitive and it was easy to see that under the traffic, the server was coping brilliantly, and the website was not generating errors or faults."
Best of all, in the lead-up to the election, we were able to add Dawn to the site during a normal upgrade, without needing an outage, so people had constant access to information about their candidates, ensuring once again that democracy was the winner on the day.
Dawn on us
Posted by on 5 October 2010
When you want to monitor sites built using the SilverStripe CMS, DawnTM is an excellent choice, so naturally, we’re using Dawn on our own websites, SilverStripe.com and SilverStripe.org, as well as on some of our clients' sites.
In the world of business this might be referred to as "eating our own dog food," but in this case, we can assure you that this metaphorical dog food is deliciously helpful.
Our Chief Technical Officer Sam Minnée uses Dawn to keep an eye on our sites. "We've optimised those pages on our site that we expected to get high traffic, but one thing that we've noticed is that we can get traffic spikes from search engines on less popular pages."
What we saw is that several search engines have been hitting silverstripe.com at the same time to index the site, spidering through all the pages. Because of the multiple hits on less optimised pages, this caused CPU and Apache usage to go up, and increased the number of database processes, all of which slowed down the whole site's performance.
"Although Dawn doesn't fix the problem by itself, it alerts us via email and text message, and provides more detailed information within the application. It can identify exactly where the issue is, tell us when it’s happening, and give us other metrics so we’re able to change the site configuration to get it solved," says Sam, "Dawn helps us identify exactly which pages are actually causing trouble, not just take an educated guess."
Each time we learn new things from Dawn, it gives us an opportunity to look at ways that we can continue to improve the service we provide to you. If you're keen to give Dawn a try, head over to our plans page and get a month's trial for free. We'd love to hear how it helps you keep your websites at their best.
Dawn brings peace of mind to Philadelphia
Posted by on 23 September 2010
You never want to hear that your site has fallen over, but when you work for the Philadelphia Police Department’s website, you really don’t want to get that call. That's why Lloyd Emelle from Hyaline Creative relies on Dawn™ .
"The main reason I was in the market for a monitoring service was because we'd receive an error usually due to a third-party [such as YouTube or Google Maps] error, and it would take the whole page down, and I wouldn't find out until someone from the police department would call me saying "hey, this page is down". If they're seeing it just then, there’s no telling how long it's been down.
"[now] I can catch it before hundreds or thousands of other people catch it. Especially when you're throwing in third party services, you need to be able to know when things go down. We're a city with a population of over one and a half million, and the police department need to be able to communicate in the language of 2010. Our 'Web 2.0' approach to public safety enables the citizens of Philadelphia to quickly find the information they need, and communicate with the department from any web browser. This means the web site must be up 24/7 and if it goes down, it must be fixed right away."
Since the Philly Police site is built using the SilverStripe CMS, it made sense to use Dawn for monitoring, as Dawn was developed with SilverStripe in mind. If there is a fault within SilverStripe code, Dawn is able to identify the nature of the problem and give a precise description, where other monitoring systems would come up with a more generic message such as "Website is not behaving as expected".
Installing Dawn was an easy task for Lloyd.
"I was surprised I didn't have to do any coding to get it to work, and I was very impressed by the installation process. Hats off to you guys for getting that right the first time around. It works. It took about five or six minutes to get installed."
Lloyd has also been impressed with the range of coverage that Dawn offers. "Page generation timing, it monitors the web server, it monitors the SQL database - extra treats! I never had any interest in knowing that type of information but it's actually pretty useful."
As Dawn is offered as Software as a Service (SaaS), it is a lot easier for Lloyd to maintain.
"If we were to build something like [Dawn], we'd be spending twice as much as we spend per month to pay a developer per hour to develop a system to monitor our web resources, and then we’d have to host that, but since Dawn is SaaS we don’t have to worry about it. All the information that we need is there and Dawn keeps a history of all the errors. We don't have to worry about the storage and things like that. It’s a good thing all around."
A major benefit that Dawn offers Lloyd is that it runs on a separate server to the Philly Police website. A monitoring system run on the police server would reduce performance, and if the web server were to go down completely, it might not be able to alert Lloyd.
He also rates the user-friendly nature of the reporting side of Dawn, which means his web designers can assess the health of the site at any time.
"The interface is awesome. Anyone can log on and use it."
With Dawn watching over the website, Lloyd can rest easy knowing the police won’t be banging down his door.
How Dawn helps you avoid disk thrashing
Posted by Sam Minnee on 8 September 2010
We just improved Dawn, our website monitoring tool, to help prevent and identify another common cause of website outages: disk thrashing.
One common cause of disk thrashing is excessive use of memory (RAM). This may be due to a large volume of traffic hitting your server, or complex pages which require significant amounts of memory to produce. In those situations, the web server begins using the hard disk instead of RAM, with dramatic consequences to performance: A platter hard disk is considerably slower than RAM, causing the server to slow to a crawl.
Swapping some memory to hard disk is acceptable in certain situations, for example, when you have Photoshop running in the background on your desktop machine. However, when a web server such as Apache begins swapping memory to hard disk to serve web traffic, it generates too much hard disk activity, which results in a severe system-wide bottleneck. You could find yourself with a web server not serving any traffic at all while hard disk and CPU activity are complete maxed out.
It's important for a website monitoring tool such as Dawn to anticipate and measure this kind of problem. In the past, Dawn has recorded physical memory usage. However, in a normal environment, you will have very little free RAM. Any RAM not used by running software will typically be consumed by file buffers: copies of frequently accessed files held in RAM to improve performance of the machine. It's therefore not useful for Dawn to show that your physical RAM is typically mostly used. What you do want to know is when the memory devoted to running programs has exhausting your RAM and thus is in danger of disk thrashing. Therefore, Dawn only measures "used" memory, excluding buffers usage and swap space.
Lastly, Dawn also measures the rate at which information is being swapped in our out, as this is effectively the measure of thrashing that your server is doing. Measuring this lets you instantly understand whether or not your server is thrashing so that you can take corrective action.
This is a great example of how our own experience of hosting hundreds of customer websites makes Dawn a better product every month. If you're keen to give Dawn a try, head over to our Plans page and get a month's trial for free. We'd love to hear how you get on!
Dawn in action
Posted by Sam Minnee on 18 August 2010
It's always great to see our stuff being used in action, solving real problems. Today, we've got a "real-world" story to tell about Dawn™.
One of the first sites we've been using Dawn for is a Wellington-based company that has about 120,000 customers, and whose primary revenue source is through its website. We host and support the site, and we use Dawn to monitor it.
In July, about a week after we started using Dawn for the site, we noticed a load spike that should have been manageable but instead caused the server to run out of memory.
We compared the Dawn graphs for memory usage and active apache processes. This helped us determine that the problem was due to the number of concurrent Apache processes becoming far too high. So we set Apache's MaxClients setting (which determines the maximum number of simultaneous Apache processes) to a better value, and adjusted our configuration to cope with load more gracefully.
The data provided by Dawn has helped us quickly identify the source of the problem and take action to resolve it, saving about 2-3 hours of developer time and potential site downtime, which would have cost the client thousands of dollars in lost revenue.
Later on in August, we found another problem. Dawn was reporting high load average and Apache process counts. Dawn sent us email and SMS, alerting us to the issue. By looking at Apache's mod_status page, we were able to see that the problem was due to to a large number of requests sitting at the "Reading Request" state, which implied a Denial of Service Attack. We solved it simply by blocking the offending IP address.
Prior to Dawn, problems such as these would often be solved only by a painstaking process of trial-and-error. In both cases, Dawn detected the problem, saved developer time and decreased downtime.
Dawn: Why do we monitor what we monitor? Part 3 of 3 - The SilverStripe Layer
Posted by on 4 August 2010
This article was written from an interview with Sam Minnée
(Continued from part two.)
The PHP/SilverStripe Level
When we were considering what information Dawn needed to gather from the SilverStripe layer, we decided upon two types. The first are errors and warnings generated by PHP. Unlike metric data, this data gives you information about specific points in time, so you can correlate certain errors with different metrics at different times. In addition to the error message, we also collect a full backtrace of the error so you can see where the error has come from.
The other piece of information we collect, which is SilverStripe specific, is the page generation time. This is the length of time that PHP spends executing.
When you request a page, there's a number of things that will happen. The client will talk to the webserver, and take a certain amount of time to get across the network. Apache will then take the request and figure out what to do with it, (and that will be relatively quick), determine it needs PHP, tells ModPHP to process the script, and then the SilverStripe bootstrap (our main PHP script), will kick off. From that point, that's when we start timing.
And then the relevant Sapphire code will be loaded, your page will process, the database will be connected, it will render templates, spit the page out to the user, and then it will get to the end of the PHP execution time. That's when we stop timing. (Specifically, we use a Register Shutdown function to trigger the end of the PHP execution, and then we write to the logfile at that time.
We collect this data in milliseconds, so this is an indication of clock time, rather than CPU time. If there are lots of processes running concurrently, the execution time may go up.
We collect execution time for different URLs but group URLs by "family." If you have a forum installed for example, there are likely many different URLs that all are considered part of the forum. Because it's the same piece of code and likely to have the same performance characteristics, we collect all of those requests under the same URL family.
Minimising the number of URL families we collect helps us with generating the roll-up data, which is averaged every five minutes, and averaged 20 minutes, average hour, average day data, etc. We also ignore all requests to the same URL with different query perimeters - that's all considered to be the same URL family. If we monitored for every URL, we'd be looking at hundreds of thousands of URLs instead of tens of thousands of URLs, for example. And that would start putting undue load on the Dawn services.
Internally at SilverStripe, we're using Dawn to help us monitor various sites we've done. But we're really keen to hear what our customers think, how Dawn can be improved, ways that our customers see Dawn could be used. We want to hear what you think.
Dawn: Why do we monitor what we monitor? Part 2 of 3 - Apache and MySQL
Posted by on 21 July 2010
This article was written from an interview with Sam Minnée
(Continued from part one.)
The Webserver Level
Apache monitoring in Dawn is done using an Apache plugin called mod_status. (Administrators of Apache will probably be familiar with it.) It gives information about the current Apache processes. We take two metrics from that - the number of working processes, and the number of idle processes.
As you might expect, if you've got too many working processes that might be a problem, but similarly, insufficient idle processes is also a problem.
Apache will basically grow the number of idle processes so that there's a certain number free all the time. Typically, an Apache will spin up and try to keep about 10 idle processes running and ready to serve requests.
If Apache can't spawn the idle process, obviously, the number of idle processes will start going down. So if you're down to, say, three or so, it's a fairly clear indication something is amiss.
If you have zero idle processes, it means your Apache server has no capability to serve another request. So we have a low value warning threshold for the idle processes and a high value warning threshold for the working processes. And this can be configured on a site-by-site basis.
For the working Apache processes, that tends to be a lot more host specific. It really depends on the amount of memory, CPUs, etc. The rough guide we use currently is that we start warning if you've got more than eight processes per core, and consider it critical at 16 processes per core.
In practice, having too many working processes and too few idle processes typically go together; but we monitor both for specifics. If there's a reason other than load that causes too few idle processes to spawn - say an Apache misconfiguration - you'll have a low idle process count even while having a low working process count.
On the other hand, large numbers of working processes impact the amount of memory you use and the amount of CPU utilisation. It is a good measure of overall load. When you see overloading, it will almost always include a large number of working Apache processes.
Because Dawn monitors multiple levels at once, you can see the combination of factors that lead to a quicker diagnosis. For example, if a disk is failing, and it is taking a long time to write to it, you'll have alot of Apache processes waiting for a long time and taking a long time to run - which means that there are many Apache processes starting. In this case, you can rule out CPU issues by looking at the CPU utilisation metric.
Similarly, if you're connecting to a third party service on every page request and it's taking a few seconds to respond, all of a sudden the number of Apache processes you have running is going to go up, even though the amount of CPU usage is fine. Each of these Apache processes, by the way, is going to use an amount of memory, and you might start to hit memory limits, which means you start swapping to disk, which will compound the problem. If you can look and say: "There are a lot of Apache processes running" before it eats up all of your memory, it gives you the chance to address the issue more quickly than you otherwise might.
Another way to look at the Apache processes is to look at the average. If the average is too high, it could indicate a systemic problem with your code. For example, this can happen if you call a third party service that takes too long to respond on every page request.
Then you've got the conditions where you have excess load. Then you're looking not so much at "is this higher than it should be" but rather "are we running out of server resources. Is our server about to break down under the load, and if so, what should we do about that?
The Database Level
Currently, at the database level, Dawn collects data from MySQL, and also looks at the number of MySQL processes.
A time-consuming Apache request usually, but not always, makes a connection to the database, so there's going to be a fairly close relationship between the number of Apache processes and the number of database processes. In unusual situations, however, they may differ, and it's exactly those unusual situations that we're looking to address.
For instance, if you had a high number of Apache working processes but a low number of database processes, that would indicate that Apache is spending most of it's time serving static requests. Which are unlikely to cause nearly as much load as dynamic requests - so if that's causing problems, it would be unusual and therefore warranting investigation.
If you have many more database requests than Apache workers, that would mean there would be other systems using the database, likely backup systems or offline processes. If this is increasing load, you may have to ask yourself, if these being run at the right time, or if there's a way we can run the processes when there is less load?
Either way, having all the data in one place builds a richer picture, and that's the common thread between all these things. Though there's a certain amount of redundancy in the different metrics we collect, by collecting them all and comparing them we have a richer picture of what our webserver is doing.
(Concluded in Part 3.)
Dawn: Why do we monitor what we monitor? Part 1 of 3
Posted by on 8 July 2010
This article was written from an interview with Sam Minnée
Overview
One of the big things we have done with Dawn is to make it flexible. We don't expect that version 1.0 will be exactly right for everyone who wants to use it, and we've built a flexible framework that we can grow as our knowledge of what people need improves.
The current Dawn product is based on our experiences and the experiences of our partners and clients. We chose what we monitor based on how we all have resolved issues over the past few years building, deploying, and maintaining SilverStripe sites. What have we used on an ad-hoc basis to try and resolve issues? Where have we gone, what have we looked at, where have we discovered issues? We added the best indicators to the Dawn monitoring system so that it would be very easy to look straight at that information all in one place.
Over time, other Dawn customers' experiences will be combined to shape how our monitoring works, but for right now, simply collecting all the data in the same place helps immensely. Rather than having one number you can look at, and know something is wrong, but not be sure what, we collect all the pieces of data you need, so you can look at all the metrics visually and figure out what's going on by the relationships among them.
The Operating System Level
At the OS level, we monitor load average, CPU usage, and memory. Load average and CPU usage are pretty closely related, although they tend to present errors in different ways. You can have quite a high load average even when the CPU usage might not be very high. That often happens in situations where something other than the CPU is holding up processes. Quite frequently, if a process is waiting for the disk, then the process may be very slow, and processes may queue up even though the CPU usage isn't really high.
Seeing load average and CPU data side by side gives you that information. If your load average is high but your CPU usage isn't, you know it's not a CPU-bound issue. It's probably related to memory or disk.
We also monitor free memory to determine if there are any issues. Running out of memory is a common pitfall, particularly on a webserver under heavy load. Unless it's carefully configured, the server gets traffic beyond the load it can handle and it runs out of memory and then things start going bad.
(To be continued in Part 2.)
Learning from history
Posted by on 22 June 2010
We designed Dawn not only to measure the status of SilverStripe websites, but also to understand how well they were performing. But how do you define “good” performance? If a site takes half a second to display a webpage, is that extremely fast, or extremely slow?
It’s all relative. Which is one of the reasons that it’s critical in any performance-monitoring tool be able to access the historical performance as well as the current performance. All of a sudden, 500 milliseconds is good if it historically took a second or more, and poor if it took far less time.
Having historical data also allows you to prove the value of changes you make to your website environment. Being able to objectively show how much a change has improved the performance of the website allows you to justify the cost of that change to the people who hold the purse string. It also lets you know when you’ve made a change for the worse, and if you can find out when the website started performing poorly, you’ll likely find the specific change that made things perform poorly.
In many ways, being able to see the past is more important than being able to see the future. Even future extrapolation in Dawn is based primarily on what trends have been continuing over the site’s history. The longer the history, the more data from which Dawn can draw predictions.
And of course, there’s no underestimating the idea that you can draw your own predictions from Dawn’s history; if your website peaks every Friday, you know it’ll likely continue to peak on Friday. Perhaps it might be a good idea to provision extra processing power only on Fridays – instead of spending the money for a full time solution.
In many ways, the power of Dawn isn’t just that it monitors your web environment and alerts you to threshold violations, but that it also gives you the context that you need to make significant decisions to improve your web environment. Because the only thing better than immediate alerts to problems is, of course, making the right decisions so you don’t have the problem in the first place.
Announcing SilverStripe Dawn
Posted by on 26 May 2010
We're very pleased to announce the release of SilverStripe DawnTM!
Dawn is a web environment monitor. And by that, we mean that Dawn monitors the entire "web environment," including the operating system, web server, database, and SilverStripe website.
We've been working hard over the past year to create Dawn. Now it's ready to see the light of day.
We originally built Dawn to meet our needs managing the SilverStripe sites we build for our clients. We realised that if we found Dawn useful, so would anyone responsible for the performance and upkeep of a SilverStripe based site.
Dawn is Software as a Service. There are a number of reasons why we chose to release Dawn as SaaS, but the main reason is that we believe monitoring a web environment is best performed as a service.
After an initial setup, all you need to do is log into a web page to see the current status of your web environment rendered in a beautiful easy-to-understand display. If you want more detail, with one click you can drill down to see heaps of useful information about the status of not just the website, but the web server, database, and operating system. We think it's pretty cool.
Part of managing a site is planning for future needs. What if you could look into the future to see how your site will perform a day from now, a week from now, or even a month from now? Dawn allows you to do just that: predictions of future state based on past behaviour.
We built Dawn on the principles of awareness, transparency, and notification. Dawn provides the tools to reliably answer questions about how a website is performing. Through notifications, graphs, and reports, you'll have a robust picture of your web environment and you'll be able to act accordingly. Finally, you can be confident about the performance of your website.
Dawn is a powerful new tool adding to what SilverStripe Ltd. can offer. We're still focused on building great sites for clients and we're still focused on open source, but Dawn helps us do those things better. And we think Dawn can help you do your stuff better, too.