> Who will pick up the mantle and actively develop the next game-changing FOSS web server?
We are writing and waiting. I don't mean to be harsh - but if you were to suggest people to ditch nginx, take the initiative and fork it and start doing the support. It's one of those "rants" we hear and nobody does anything.
> Getting these NGINX log events into a remote server is easy with rsyslog. But preventing the log events from writing to disk in the first place?
And what is the problem with writing to disk? I guess RAM disk is fine? I am not really sure what's the issue with writing to disk. Most of the time it's the application and securing disk more important.
I still don't see any convincing argument why we should ditch Nginx. To me all the points so far is about Nginx going commercial.
I think OP's issue is that writing to disk will break his old NetApp install.
I don't think it's really that bad to write the local logs to ramdisk and then have the centralized logging system pull the logfiles every so often as a stopgap. VMs are meant to be ephemeral anyways.
While ephemeral VMs are a great way to operate if your able, I really don't think you can say that your "meant" to operate that way.
Many workloads don't fit that model, and certainly a lot of commercial software is of the type that your not going to want to be re-installing too often and going through re-licensing hell.
>I don't mean to be harsh - but if you were to suggest people to ditch nginx, take the initiative and fork it and start doing the support.
Perhaps he doesn't have the hours/skills free to do so. People are free to complain about things or do a 'call-to-arms' about things they can't fix themselves.
>And what is the problem with writing to disk?
Performance
>I guess RAM disk is fine?
It works, but it's a hack and major technical debt to hold.
> I am not really sure what's the issue with writing to disk.
Performance. Specifically the thundering herd problem. All of his servers log to virtual disks all stored on the same SAN, which is stressing under the load.
>I still don't see any convincing argument why we should ditch Nginx.
It's a bit of a slippery slope fallacy, but the point is that a basic feature is being held hostage behind a pay-wall. It would be like MySQL requiring you to pay to any users other than the 'admin' SQL account.
Perhaps he doesn't have the hours/skills free to do so. People are free to complain about things or do a 'call-to-arms' about things they can't fix themselves.
I think in the case of open source we have far too many people who feel entitled to the work of others without any recompense already. Working on a large OS project like this is mostly a thankless task - people will complain about the problems while taking for granted all the features that just work, and they're unlikely to be raking in lots of money because of attitudes like this.
Given the volume of sales, the 3 floor building and the use of NetApp, I would have thought this company has money to pay nginx for what is a core piece of software, even if they have to negotiate a special license or change their setup. If they don't want to or can't, they can use apache, find workarounds, or even patch nginx themselves.
Issuing a call to arms over this is pretty obnoxious behaviour, because it implies the nginx people have done something wrong or antisocial in wanting to be paid for some of their work. How outrageous!
the point is that a basic feature is being held hostage behind a pay-wall. It would be like MySQL requiring you to pay to any users other than the 'admin' SQL account.
Yes, it would be like that (though this feature is more trivial and could be worked around, and is not an existing feature, so not exactly the same). That's the way companies make money when they segment their market and have an OS offering and a commercial one. Nothing wrong with that. If you don't like the rules set by the creators, don't use it; write your own software or use other software. If they had retrospectively retired features and put them into the paid version, perhaps he'd have a point, but as far as I'm aware they haven't.
He's not entitled to have the nginx guys work for free forever on his terms on their software. Ending with the exhortation 'Fork it' sums up his position perfectly - someone else should fork this software, add the features I need, and then continue to work for free for me. He's asking 'Who will pick up the mantle', because clearly it won't be him; he's not a sucker after all.
>Yes, it would be like that (though this feature is more trivial and could be worked around, and is not an existing feature, so not exactly the same). That's the way companies make money when they segment their market and have an OS offering and a commercial one. Nothing wrong with that. If you don't like the rules set by the creators, don't use it; write your own software or use other software. If they had retrospectively retired features and put them into the paid version, perhaps he'd have a point, but as far as I'm aware they haven't.
But what they have done is made a pretty basic marketing mistake. They decided to charge for something that has been 'solved' by apache and hundreds of other pieces of software many years ago. People don't want to pay for something that's not new in the field.
>Issuing a call to arms over this is pretty obnoxious behaviour, because it implies the nginx people have done something wrong or antisocial in wanting to be paid for some of their work. How outrageous!
You say that like all approaches to making money are the same and it's disingenuous. How about some document editing software that works for free for 30 days and then encrypts all of your files until you pay up? The developers just want to get paid, right? How outrageous!
>If you don't like the rules set by the creators, don't use it; write your own software or use other software.
That's what he's advocating...
>Ending with the exhortation 'Fork it' sums up his position perfectly - someone else should fork this software, add the features I need, and then continue to work for free for me. He's asking 'Who will pick up the mantle', because clearly it won't be him; he's not a sucker after all.
That's exactly what good open source foundations do. I take it you are unfamiliar with the apache web server project? What about OpenStack? Maybe Linux or Firefox? None of these projects turn to their users to squeeze money out of them to activate basic features.
>What about OpenStack? Maybe Linux or Firefox? None of these projects turn to their users to squeeze money out of them to activate basic features.
Thats disingenuous. Linux squeezes money out of users via RHEL and SUSE. Firefox straight up sells your data to Google (who in turn provides over 90% of Mozilla revenue).
Even Apache, a "good" open source foundation, houses Cassandra, which is largely contributed to by DataStax, which sells its own version of Cassandra which has "pay-only" features such as Hadoop integration without the need of HDFS.
Long story short, there are large number of OSS that function the way nginx is running things right now. You could probably throw a pebble in the OSS/Enterprise ocean and land on a project that has "pay-only" features. Unless you are willing write the solution yourself, no one in obliged to take up the mantle and fix your problems for you.
> Linux squeezes money out of users via RHEL and SUSE.
Linux is not RHEL and SUSE. You can use Linux without using RHEL and SUSE and still get all of the Linux kernel features, which is the entire point. That's exactly what makes it a good foundation. They aren't arbitrarily screwing their users out of features. There is no such thing as an 'enterprise-plus Linux Kernel'.
> Firefox straight up sells your data to Google (who in turn provides over 90% of Mozilla revenue).
This is a blatant lie that shows nothing more than your ability to troll. If you can't handle a specific search provider getting your data when you search, change your search provider.
>Even Apache, a "good" open source foundation, houses Cassandra, which is largely contributed to by DataStax, which sells its own version of Cassandra
It doesn't matter, you seem to be failing with basic logic. Cassandra may be contributed to by DataStax, but DataStax doesn't control the gate so they can't stop contributions that overlap with their product's functionality. nginx can and does stop patches that duplicate 'enterprise functionality'. See the problem?
Maybe I should have provided a source, but calling something that is easily google-able and was on the front page on HN a "blatant lie" is worrying. Why would I lie on the internet?
>Cassandra may be contributed to by DataStax, but DataStax doesn't control the gate so they can't stop contributions that overlap with their product's functionality.
Again, you should research your claims before assuming I'm lying. The project chair for Apache Cassandra is also the Co founder of DataStax - so yes, DataStax does control the gate.
No, he's not. He's advocating that someone else needs to do that work for him, so that he can benefit. He's explicitly asking other people to do the work at the end:
Who will pick up the mantle and actively develop the next game-changing FOSS web server? Fork it!
NB that statement was not - perhaps I will fork it, or perhaps I will contribute to a new FOSS web server, or should we help nginx solve this issue some other way, but a plea to someone else to do all the hard work so that he can use it for free.
You say that like all approaches to making money are the same and it's disingenuous.
That wasn't the intention or I believe the implication, the analogy above about locking user data away is absurd and unhelpful.
That's exactly what good open source foundations do. I take it you are unfamiliar with the apache web server project?
Some OSS works on the model of selling services, some works on the model of selling extra features and commercial licenses. Personally I'm agnostic as to which is best, but this is not a new or unusual development. Many companies from Ubuntu to Firefox do commercial deals and request money indirectly or directly to support their product. If you don't like those deals or disagree with the particular method used, you can use other software, but whining about it is not productive.
This position is without merit. People have every right to say that one particular free option is not what they're looking for, and explain why it's not what they're looking for.
While I agree with your statement on it's face, in the context of the OP, this is just whinging. The author is not just offering constructive criticism on a possible fork of NGINX, he's calling the NGINX business out for "withholding" features. The tone is distinctly one of being "owed" a feature common to another popular FOSS project, instead of being grateful for everything NGINX provides (which is a lot, and probably why switching to Apache is suggested with some reluctance in the OP).
This part of FOSS culture I really dislike as a developer.
Many people seem to consider an offence that other developers need to make a living, instead of being grateful of being able to sell stuff using software they haven't paid a dime for.
Then become outraged when the developers come to the conclusion that the baker won't sell bread for pull requests.
This is what moved me into the direction of suggesting dual license for open source projects, every time someone consults me on it.
What you are suggesting is the part of a greedy FOSS project. One that enjoys the external open source contributions, yet still charges for features in the software. It's disgusting and an insult to your contributors, unless you pay them all money as well.
There is nothing wrong with making money, but don't to it with sleazy tactics like this that put you in a conflict of interest. Charge for support or a hosted version, but don't artificially cripple the software. If you do want to go that way, don't be open source at all because you are just a leech on the community.
I am all for charging for support or hosted versions. However this usually only suits server side software or developer tools. There are plenty more of other types of software.
What I dislike are the companies that just use FOSS as free beer, specially in closed source products or behind SaaS walls.
So when asked for advice what type of license one should give to their projects, my recommendation is always to go GPL for open source projects. If the developer community gets contacted by commercial vendors, then either create a special license for the respective vendor, or have a general one for those type of cases.
But always use a license that prevents people selling your work as theirs.
> What you are suggesting is the part of a greedy FOSS project. One that enjoys the external open source contributions, yet still charges for features in the software. It's disgusting and an insult to your contributors, unless you pay them all money as well.
What I love the most about the author's post is the "fork it" part.
The author goes out of his/her way to pick out what's wrong with NGINX due to the inadequate SAN infrastructure and at the end suggests someone else fork the project so his/her company can continue to milk the free software of the backs of others.
>The author goes out of his/her way to pick out what's wrong with NGINX due to the inadequate SAN infrastructure
Wrong. NGINX has recognized this as a problem and discovered apache solved it years ago for a reason. So they decided to play catch-up, but charge for it.
>company can continue to milk the free software of the backs of others.
>It's somewhat disgusting.
That's FOSS. If you don't like it, don't use it. What NGINX is doing is disgusting. The FOSS community actively invested in NGINX via external patches, documentation, bug reports, how-to's, chef-scripts, etc and NGINX is paying everyone back by charging for features.
I agree with you. If you don't like it don't use it.
I don't have any problems with the author's discussion on the issue's with NGINX, but the solution to the problem is not to say its time for a fork and for a better product to come along. That's pretty much an ultimatum type argument and no one likes that.
Especially if the author has no stake in the actual development. It's one thing for Linus Torvalds to be abrasive (he's earned the right) versus being abrasive without any real foundation (I didn't get the impression that the author is a strong contributor to the project).
He's calling for action from others, which opens him to criticism from other people about his motives, his reasoning and his tone. Remove the entire last paragraph and closing sentence (another call to action!) and you will probably agree that the tone of the post changes completely.
Sigh. FOSS and NGINX as an example of FOSS have given us so much. If direct to syslog logging is what you're after, why not use Apache? As many people have pointed out before, Apache can certainly be hold a candle to NGINX if you put the time into tuning it. If you're expecting Black Friday traffic of this magnitude, and you haven't spent the last two months planning and load testing for it, you are either lazy or underpaid. If the first, okay, I get why you don't want to roll your own RPM. If the second, that's just what this business can expect out of their setup.
No one is going to dump NGINX over this. If it is this mission critical to your business, pony up and pay for NGINX.
> We’re using php-fpm anyway; the performance difference between nginx and httpd in this scenario is negligible.
So why are we even having this discussion? Honestly if you're experiencing that much traffic and PHP performance is hindering you, you should consider some sort of Varnish full-page caching anyhow. Disk writes, as you note, are not your primary issue, and certainly is no reason to dump NGINX.
Reading this post, I'd assume that this time next year, if the company is still there and this guy still has this job, they'll still be using nginx. Someone dropping this sort of frustrated blog post about how his company should dump it probably doesn't have the authority to make that call or the motivation and time to make it happen if he does.
The whole tone of the blog post is passive-aggressive, whether directed at the makers of nginx (for wanting to get paid), or at the end, towards some hypothetical people who take it upon themselves to build a fork that suits all his needs (despite his not actually needing such a fork). Such a tone suggests that he feels powerless.
Then ditch it and move on. If everyone made a post every time they chose not to buy X product but instead to use Y product then HN would be unreadable.
You have the source, patch/fork it. If you're too lazy/not skilled enough, switch to Apache and don't tell us about it.
Although I share your sentiment, noc and devops people are legitimately paranoid about stability, so no, he's neither lazy nor unskilled - this part I can easily believe. What I can't understand is, if they have tons of traffic and he admittedly uses a product he likes, why doesn't he just pay for it. FOSS does not enslave its authors to perpetually provide free infinite scalability for every use case.
Very true. Forgot to mention that part. Why not pay for a great product if you find it useful. I've paid for FOSS stuff before, and supported distros I use...
The article's actual title is "Apache 2.4 Faster Than Nginx?" . As most articles having a question mark at the end of their title, not surprisingly the answer is "no" ... Quoting from the article itself:
>> It turned out that it’s a false claim. Apache 2.4 is actually much slower than Nginx!
Performance is pretty good in Apache 2.4, but compare RAM usage alongside NGINX and you'll notice that NGINX's event based threads approach takes a big dump all over Apache's separate process lets consume every bit of available RAM the server has until it starts throwing errors and filling log files. Apache is getting better, but it's not really on par with NGINX (yet, but it will be).
You didn't hear what he said, he's specifically not talking about the memory hogging process bases mpm. You seem to think Apache only works that way, but the worker modules are pluggable.
He's talking about Apache MPM Worker which while offering better performance over the traditional Apache MPM Prefork because it's threaded based like NGINX is, it still consumes more RAM than NGINX does, so my point remains...
> NGINX's event based threads approach takes a big dump all over Apache's separate process lets consume every bit of available RAM the server has until it starts throwing errors and filling log files.
No your point doesn't stand, your point is completely wrong because you don't know what you're talking about. Go back read the crap you wrote before claiming your point still stands.
I'm curious what business model the author of the post thinks would be possible for the author of nginx and not result in this scenario for feature x/y/z?
Also, as an aside, it seems like the author of the post pays for NetApp and the very, very expensive support contracts that come with it, nginx contracts are a walk in the park, financially, in comparison.
> I'm curious what business model the author of the post thinks would be possible for the author of nginx and not result in this scenario for feature x/y/z?
The author presumably belongs to the same cohort who download films and music without paying and sneers "how you feed yourself isn't my problem, go sell some t-shirts or something". I doubt the author gives a shit, they just want stuff for free, so they can continue to make money with it.
"Poe's law, named after its author Nathan Poe, is an Internet adage reflecting the idea that without a clear indication of the author's intent, it is difficult or impossible to tell the difference between an expression of sincere extremism and a parody of extremism."
Given the content of at least 1 other related site hosted on the same IP (simulantproductions.com), I think it's fair to say this article is satire and should be considered flamebait.
I can't tell if this post is serious or not (the domain name throws me off a little). I use NGINX myself, but I am also aware that Apache is playing catchup quite quickly as well and Apache 5.4 is a decent version of the popular open source server.
Use whatever fits your needs, just because it didn't fit your needs doesn't mean you should go forcing your opinion upon others. Many people including myself have had nothing but great experiences using NGINX and I don't actually see any real argument here to stop using NGINX.
Based on the tone of the article I get the kind of vibe that the author has the "I liked this band before they became mainstream" mentality about software. NGINX deserves all of the money they can get, they have a great product that is worth paying for and it's quite usuable without paying a cent, so I don't understand what there is to complain about.
This blog post demonstrates why the syslog feature is ideal for segmenting Nginx's market.
Almost nobody cares about it, except the sort of place doing > tens of millions of requests per day. The sort of place that might have some money and the scale to realise that a few thousand bucks is cheaper than a bunch of engineer time.
>I don’t blame NGINX for wanting money in exchange for what is admittedly amazing software. I just don’t want any part of it.
Why not? You're using this awesome software whose value you appreciate and which is, you admit, open source. It's just not convenient enough for you. So why can't you pony up the money for your huge, high-traffic website?
>Yep, they took a feature that Apache httpd has had literally forever and put it behind a pay wall.
Charging for support is one thing, but this seems like it should be a basic feature.
And if I were running a server farm on FOSS software and then realized I'd need to cough up ($1350 * ~100) around $135k for the ability to disable obnoxious behavior, because the corporation arbitrarily decided that this particular feature (that most every other HTTP daemon worth a crap has had for ages) was the one that they're going to require you to pay for, I'd be a bit scandalized too, probably enough to write a blog post about how much it annoyed me.
It's perfectly reasonable to cringe at a $135K price tag. But if that's so onerous, why not spend a day compiling the source and setting it up for distribution on your servers? The answer is that you (or at least the hypothetical you) feel entitled to this software packaged how you want it with the features you want.
If you want to use Apache, use Apache. That's totally your right. Or you can fork NGINX and do whatever you want. It's even got a BSDish license to make that easy. You could even use the last version of the software that baked this feature into the standard distro. But you're using the official NGINX distro for a reason, and I don't see why the people who make it shouldn't demand a bunch of money for whatever that reason is.
To be clear, it's perfectly fine to say, "I don't think this is a good feature to put behind the paywall." I'm just balking at the whiny and entitled tone of the original post. "How dare they ask me to pay for the things I want!" If I were trying to monetize an open source project, per Jacques's comment above, this is exactly the kind of high-scale feature I'd target for that.
>To be clear, it's perfectly fine to say, "I don't think this is a good feature to put behind the paywall." I'm just balking at the whiny and entitled tone of the original post. "How dare they ask me to pay for the things I want!" If I were trying to monetize an open source project, per Jacques's comment above, this is exactly the kind of high-scale feature I'd target for that.
And you would be an anchor dragging the project down. You aren't considering the angle of external contributors. As someone who submits patches to open source projects, I would be pretty damn pissed if the project I spent hours/days/weeks learning the architecture of pulled some shit like this. Especially if they rejected a patch because the feature in the patch was too 'useful'. Disgusting.
How long do you think you will keep getting external contributors when they can't even use the full software and are afraid to put the work into patches because they might conflict with the 'enterprise offering'?
If you open source something and allow external contributors, you are going to receive this entitled tone when you pull these shenanigans.
> As someone who submits patches to open source projects, I would be pretty damn pissed if the project I spent hours/days/weeks learning the architecture of pulled some shit like this.
That's a good point, and I agree. But that's not the perspective being presented by this article, as far as I can tell.
It's pretty simple actually: We don't have an HTTP server software budget. The expectation is that the tech team will choose the right tools for the job and ask for paid tools when we need them (eg. New Relic). NGINX doesn't differentiate enough from the other HTTP servers out there to justify the cost.
What angst? That post reads more like a warning to others to me - after all, if they'd been aware of this issue from the start, they could've just used Apache from the beginning and avoided the hassle of having to migrate.
>NGINX doesn't differentiate enough from the other HTTP servers out there to justify the cost.
From the post:
>admittedly amazing software
It sounds, honestly, like you're never going to pay for OSS. That's fine if that's the way you want to do things, but to then write a post entitled "We should ditch NGINX" seems way over the top.
Because you depend on a tool that you're not willing to pay for .. is it so difficult to see that you are being viewed as a bit of a scrooge, given that you will profit greatly from software you don't own and haven't paid for .. ?
First, there is no proof of how much profit comes from nginx in a stack with PHP so you can drop the 'profit greatly' line.
Second, the entire point of open source software and the FOSS movement is that you shouldn't be extorted for functionality. Do you harass people that file bug reports or submit requests for features to the Linux Kernel for not paying?
Are you or are you not running a business with FOSS? It was Free: so any USE of the software that you get out of it, was profitable. What part of "this is free, so anything you do with it is profitable" do you not agree with?
Second: extortion, really? Thats what you're calling this, in the same breath as admitting that you won't/can't/are unwilling to pay for software that is a key part of the production line?
The entire point of FOSS is being able to have the source code of the software you use. Period. That's it.
The people who write the software can do whatever the hell they want, as can the people using the software, as long as they abide by the licence. These are the only stipulations. Even RMS supports the right of creators to sell software.
People who write FOSS software aren't required to be a charity...
> People who write FOSS software aren't required to be a charity...
I think this is a point so many users of FOSS miss. I'm an ardent supporter of FOSS, but I don't get to act entitled unless I'm paying someone (and probably not even then).
The over-the-top part is where you use the stigma from your story (how nginx spurned you by choosing to charge you for a particular feature, which does not seem fair to you because you need it) to try to get everybody to stop using it, when the issue is simply that it does not suit YOUR needs.
If nginx has no features that set it off feom other servers you could simply switch to Apache which has the syslog feature. But for some reason you do not seem to do this, or am I mistaken?
"NGINX Plus Standard" costs $1,350 annual subscription per server. It sounds like this company has a pretty strange setup, running "hundreds of VMs", presumably all running nginx, and it's the combined impact of those VM logging writes that are so burdening the NetApp devices.
In this case, if they kept the same setup, I can see that it would be prohibitively expensive to pay for nginx plus on every single one of those VMs. I'm not sure of the nginx's license terms but if they count VMs as a separate server - probably a no go.
A better solution might be to turn all those VMs into application servers and put a big meaty nginx reverse proxy in front of them; that sounds like it would reduce the nginx bill but could be an awful lot of work. Then again, I presume they have automation, you'd hope so with hundreds of VMs...
My point is that it's likely not quite as simple as a grand a year, which would likely be a no-brainer if it was a site license.
I am not disagreeing that in this specific case that the licence structure might lead to unhappy arithmetic. I do however stand by my original point that syslog support is an excellent cleavage point to segment the customer base.
I'm slightly less happy about the HTTP live streaming being in the Plus package, though. I've been playing around a lot with a media app using HLS and I can't even trial using nginx for it - not that I'd be too happy paying $1300 a year since I don't have a single user yet. I can see how they are trying to get money out of the big streaming companies, but it's not too friendly to the little guy.
Segmentation is a lossy function, unfortunately. If you try too hard to fit the price/feature curve by creating too many segments, you wind up with nonsense like Windows Home Professional Premium Plus Ultimate Edition.
FYI, you might want to try nginx-rtmp-module (https://github.com/arut/nginx-rtmp-module); HLS support is one of its advertised features. I've been using it for RTMP and it's been working flawlessly.
>I do however stand by my original point that syslog support is an excellent cleavage point to segment the customer base.
Probably because you are not a systems engineer. Did you see what it resulted in here? Many of the people who have systems large enough to hit these issues will just work around it using the ramfs approach or by just dumping nginx. Either way you have a skilled engineer disappointed in your product.
Don't differentiate FOSS with paid on something that simple, especially something that has been supported by apache for almost a decade.
first, that price is almost certainly negotiable, particularly if you call and say "i'm running a ton of light vms for some strange reason"
second, I think, at least for me, what bugs me is the massive entitlement on display. God forbid devs who built an awesome piece of software get paid; instead, dude whinges on the internet that he might have to gasp patch and compile an rpm or fork out some money. The horrors!
>second, I think, at least for me, what bugs me is the massive entitlement on display. God forbid devs who built an awesome piece of software get paid; instead, dude whinges on the internet that he might have to gasp patch and compile an rpm or fork out some money. The horrors!
On the surface yes, but consider the betrayal to all of the external contributors. Is the money going to them too? What about the people that wasted time proposing a patch that overlapped with this 'enterprise feature'. Open source is not a one-way street.
So, I found myself in a similar position recently with a technically FOSS project. The patches I was submitting were being re-licensed under a commercial license and sold to enterprise customers. I had to sign contributors agreement before sending patches and after the fact I found myself having a philosophical issue with them selling my work. As a consequence, I stopped submitting patches to the main project and instead maintain my own patch repo now.
While I find the wholesale re-licensing of the codebase under a commercial license reprehensible, I agreed to that before committing code. That leaves me with one remedy, not committing additional code.
As a side note, this project had a basic FOSS version and an enterprise version with additional functionality. The only part of what they did that I took issue with is re-licensing the FOSS portion under a commercial license. Had they left the FOSS portion under the OSS license and simply added commercial code on top I would have 100% continued to commit patches.
At these volumes, nobody really would multiply one server price tag per amount of VMs. That's when people negotiate. So 135k price tag is probably purely imagined.
Some people are just jerks. They're the same people who are problem customers for products they pay for too, and probably the same people cutting you off in traffic and not tipping their waiter when they go out to dinner.
They aren't self-entitled if the project has any sense of community and has accepted external contributions of code/documentation/etc. Lots of external hours go into projects like this and moves like these are myopic and generally a big 'screw-you' to active external contributors.
External contributors are usually not the problem, since they're intimately familiar with the project and know just how much time and effort the core team invests in it to keep it running. Contributors that have had a positive impact are usually given free commercial licenses, thanking them for their efforts.
The 'screw you contributors' is a common argument used by self-entitled users to try and shame core maintainers into continuing to devote all their future efforts, giving away all their future time and IP away for free - just so they can continue their unfettered use of everything they make, and for them to continue to provide support, so that end-user commercial products can continue to benefit from all their future efforts, uncompensated.
Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog. My team made a patch to have it log to UDP multicast, and it wasn't too bad. If you're really pissed at the nginx guys, contribute the patch back.
Sure, I quibble with their approach to a commercial model, but I really think this is a case of "me thinks she doth protest too much" in both the literal and implied meaning.
> Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog.
Be careful with high performance expectations on named pipes. The fifo is in memory, but the inode is on disk. It really sucks to block on stat() and friends when you dont expect it. Oh! And those FIFOs act as a 64kb buffer. Need more buffering? Put another pipe on it!
syslog is also a syscall, and has limited buffering. A named pipe can actually potentially amortize overhead more effectively. (And just because an inode is involved does not mean that a call to stat() involves a trip to disk.)
If you are really worried about buffering, you can always have a consumer of the named pipe with its own buffering before writing to syslog (yes, that can get ugly).
In a perfect world, I'd actually prefer to write to a ring buffer in shared memory (one per worker to avoid too much contention) and then have another process that empties it as fast as it can.
Either way, it's actually not that hard to hack in to nginx. If someone were to contribute a patch that did logging the "right" way and host it on say... github, I think you'd find the nginx commercial folks would have a response that works out pretty well for everyone. The catch is, it requires someone to do something.
As I said, I have quibbles with their commercial model. I get the problem.
In reality though, you can always fork, which puts pressure on them to embrace desirable patches if they are provided from outside, and to move their enterprise features into the main branch. If they keep stuff out of the their main branch that people can route around, it significantly reduces the commercial value they can realize.
CloudFlare generates 50gb/s of logs globally and have handled collecting this volume in two ways. Historically the logs are sent to a local syslog-ng through the use of a PIPE and the forwarded to central logger. This can be done with nginx with no patches by just treating the PIPE as file. Just make sure you do a little buffering inside nginx.
We will write up a blog post at some point but hopefully this is useful to you. In the future we are going to be going one step further and have NGINX emit protobuff files. Feel free to email dane AT cloudflare.com if you have any questions.
Apologies everyone for the somewhat o/t question here but, what do you guys do with your 50Gb of logs every second? Where do they go after they leave nginx?
To be 100% clear: we have never been asked or ordered to share log data with the NSA. We've not participated in any program like PRISM and would fight vigorously if we ever were. We do receive law enforcement requests on occasion, typically to determine who owns or hosts a site behind our network. When we've received law enforcement requests for customer data (e.g., account information like the email address of an account) which we determine are abusive or do not follow the principles of Due Process we have and will continue to go to court to fight for the rights of our users. Whenever possible, even if the legal request meets our standards, we also notify customers of legal requests and allow them to challenge the requests themselves before turning over any data. We take this extremely seriously and spend significant technical, legal, and public policy resources to ensure law enforcement's job is neither easier nor harder by the mere existence of CloudFlare.
Sure, but why should I have any reason to believe you?
If you had been served with a national security letter, you would be obligated to lie about it.
Plus, you have a pretty significant financial incentive to lie about how great Cloudflare is, with no downside, since you're not under oath on HN. And even if you were, officials who have lied about the extent of surveillance programs while under oath haven't been prosecuted.
Representatives of Facebook lied. Ditto with Google. Etc, etc, etc.
No. National security letters can act as gag orders, obligating you not to talk about their existence but you're never required to lie and say you have never been served a letter.
In that case, you can be cagy (as Google has I believe) and say something on the lines of "I can neither confirm nor deny receiving a NS letter" which of course is double speak for "I have one, and I can't talk about it directly".
For most customer they are stored just long enough to provide support, create aggregates for the analytics dashboard, and update threat profiles. Our enterprise customers have the option collect raw logs through SFTP for up to 3 days.
TL;DR: we generate logs at the edge, those are turned into aggregates to display analytics data (e.g., page views, hits, bandwidth), then logs are discarded unless you're an Enterprise customer in which case we allow you to download the raw log data for 3 days.
50gb/s ofCloudFlare logging data to "data science" at sounds like the most interesting damned problem I've ever heard. Well, probably second to how you manage that flow into a pipeline in the first place.
That is a mind blowing amount of data. Is this all access/error log data, or are there other logs being generated?
If it _were_ access log only, and your log lines average 1KB in length (pretty generous), that's 52m qps. If we take that further and assume each object is 93KB [1] then your outbound traffic is almost 40Tb/s (terabits per second).
So I assume it must be more than just access logging!
Not relating to the Author's opinion, I would just like to know if there's a legitimate, competent competitor to Nginx apart from Apache? Just curious as I've already had a bad experience with monopolies in the past.
Just want to mention that HAProxy isn't a web server like nginx, but a proxy. So while it competes at some things nginx is commonly used for, its not a full competitor (you wouldn't replace nginx+php-fpm w/ HAProxy+php-fpm).
That said, if you're looking for a proxy/load balancer, HAProxy is most likely the absolute best you're going to find anywhere, ever...and the price is right ;)
It's $1350/server per year to pay for the feature. You mention in your post: "Our noble HTTP server". Wait. Not plural? I know that a that is a fair bit of money for a bootstrapped startup, but if you are anticipating enough traffic that the syslog feature is an issue, AND you have at least three floors of offices (as mentioned in your blog post), then maybe your OPEX prioritization is a bit off, and you should just pony up.
Nginx is a great piece of software for $no dollars, maybe it would be good karma to pay for the extras you need?
Yes, $1350/server per year * 100 VMs which just broker requests from clients to php-fpm. Totally reasonable. /s
For that price, they could pay someone who's sole job is to maintain a private fork with the feature. It's not like they can submit it back since nginx would reject an enterprise competing patch, but at least they would have the functionality and the benefit of another dev on hand.
So is that about the pricing or the closed source? Would it be different if the pricing was something else? Just curious. Also, like quite a few people pointed out, why not request "the best pricing" given certain deployment scenario?
175 comments
[ 5.2 ms ] story [ 230 ms ] threadWe are writing and waiting. I don't mean to be harsh - but if you were to suggest people to ditch nginx, take the initiative and fork it and start doing the support. It's one of those "rants" we hear and nobody does anything.
> Getting these NGINX log events into a remote server is easy with rsyslog. But preventing the log events from writing to disk in the first place?
And what is the problem with writing to disk? I guess RAM disk is fine? I am not really sure what's the issue with writing to disk. Most of the time it's the application and securing disk more important.
I still don't see any convincing argument why we should ditch Nginx. To me all the points so far is about Nginx going commercial.
I don't think it's really that bad to write the local logs to ramdisk and then have the centralized logging system pull the logfiles every so often as a stopgap. VMs are meant to be ephemeral anyways.
While ephemeral VMs are a great way to operate if your able, I really don't think you can say that your "meant" to operate that way.
Many workloads don't fit that model, and certainly a lot of commercial software is of the type that your not going to want to be re-installing too often and going through re-licensing hell.
Perhaps he doesn't have the hours/skills free to do so. People are free to complain about things or do a 'call-to-arms' about things they can't fix themselves.
>And what is the problem with writing to disk?
Performance
>I guess RAM disk is fine?
It works, but it's a hack and major technical debt to hold.
> I am not really sure what's the issue with writing to disk.
Performance. Specifically the thundering herd problem. All of his servers log to virtual disks all stored on the same SAN, which is stressing under the load.
>I still don't see any convincing argument why we should ditch Nginx.
It's a bit of a slippery slope fallacy, but the point is that a basic feature is being held hostage behind a pay-wall. It would be like MySQL requiring you to pay to any users other than the 'admin' SQL account.
I think in the case of open source we have far too many people who feel entitled to the work of others without any recompense already. Working on a large OS project like this is mostly a thankless task - people will complain about the problems while taking for granted all the features that just work, and they're unlikely to be raking in lots of money because of attitudes like this.
Given the volume of sales, the 3 floor building and the use of NetApp, I would have thought this company has money to pay nginx for what is a core piece of software, even if they have to negotiate a special license or change their setup. If they don't want to or can't, they can use apache, find workarounds, or even patch nginx themselves.
Issuing a call to arms over this is pretty obnoxious behaviour, because it implies the nginx people have done something wrong or antisocial in wanting to be paid for some of their work. How outrageous!
the point is that a basic feature is being held hostage behind a pay-wall. It would be like MySQL requiring you to pay to any users other than the 'admin' SQL account.
Yes, it would be like that (though this feature is more trivial and could be worked around, and is not an existing feature, so not exactly the same). That's the way companies make money when they segment their market and have an OS offering and a commercial one. Nothing wrong with that. If you don't like the rules set by the creators, don't use it; write your own software or use other software. If they had retrospectively retired features and put them into the paid version, perhaps he'd have a point, but as far as I'm aware they haven't.
He's not entitled to have the nginx guys work for free forever on his terms on their software. Ending with the exhortation 'Fork it' sums up his position perfectly - someone else should fork this software, add the features I need, and then continue to work for free for me. He's asking 'Who will pick up the mantle', because clearly it won't be him; he's not a sucker after all.
But what they have done is made a pretty basic marketing mistake. They decided to charge for something that has been 'solved' by apache and hundreds of other pieces of software many years ago. People don't want to pay for something that's not new in the field.
>Issuing a call to arms over this is pretty obnoxious behaviour, because it implies the nginx people have done something wrong or antisocial in wanting to be paid for some of their work. How outrageous!
You say that like all approaches to making money are the same and it's disingenuous. How about some document editing software that works for free for 30 days and then encrypts all of your files until you pay up? The developers just want to get paid, right? How outrageous!
>If you don't like the rules set by the creators, don't use it; write your own software or use other software.
That's what he's advocating...
>Ending with the exhortation 'Fork it' sums up his position perfectly - someone else should fork this software, add the features I need, and then continue to work for free for me. He's asking 'Who will pick up the mantle', because clearly it won't be him; he's not a sucker after all.
That's exactly what good open source foundations do. I take it you are unfamiliar with the apache web server project? What about OpenStack? Maybe Linux or Firefox? None of these projects turn to their users to squeeze money out of them to activate basic features.
Thats disingenuous. Linux squeezes money out of users via RHEL and SUSE. Firefox straight up sells your data to Google (who in turn provides over 90% of Mozilla revenue).
Even Apache, a "good" open source foundation, houses Cassandra, which is largely contributed to by DataStax, which sells its own version of Cassandra which has "pay-only" features such as Hadoop integration without the need of HDFS.
Long story short, there are large number of OSS that function the way nginx is running things right now. You could probably throw a pebble in the OSS/Enterprise ocean and land on a project that has "pay-only" features. Unless you are willing write the solution yourself, no one in obliged to take up the mantle and fix your problems for you.
Linux is not RHEL and SUSE. You can use Linux without using RHEL and SUSE and still get all of the Linux kernel features, which is the entire point. That's exactly what makes it a good foundation. They aren't arbitrarily screwing their users out of features. There is no such thing as an 'enterprise-plus Linux Kernel'.
> Firefox straight up sells your data to Google (who in turn provides over 90% of Mozilla revenue).
This is a blatant lie that shows nothing more than your ability to troll. If you can't handle a specific search provider getting your data when you search, change your search provider.
>Even Apache, a "good" open source foundation, houses Cassandra, which is largely contributed to by DataStax, which sells its own version of Cassandra
It doesn't matter, you seem to be failing with basic logic. Cassandra may be contributed to by DataStax, but DataStax doesn't control the gate so they can't stop contributions that overlap with their product's functionality. nginx can and does stop patches that duplicate 'enterprise functionality'. See the problem?
Source: http://thenextweb.com/insider/2013/11/21/mozillas-reliance-g...
Maybe I should have provided a source, but calling something that is easily google-able and was on the front page on HN a "blatant lie" is worrying. Why would I lie on the internet?
>Cassandra may be contributed to by DataStax, but DataStax doesn't control the gate so they can't stop contributions that overlap with their product's functionality.
Again, you should research your claims before assuming I'm lying. The project chair for Apache Cassandra is also the Co founder of DataStax - so yes, DataStax does control the gate.
No, he's not. He's advocating that someone else needs to do that work for him, so that he can benefit. He's explicitly asking other people to do the work at the end:
Who will pick up the mantle and actively develop the next game-changing FOSS web server? Fork it!
NB that statement was not - perhaps I will fork it, or perhaps I will contribute to a new FOSS web server, or should we help nginx solve this issue some other way, but a plea to someone else to do all the hard work so that he can use it for free.
You say that like all approaches to making money are the same and it's disingenuous.
That wasn't the intention or I believe the implication, the analogy above about locking user data away is absurd and unhelpful.
That's exactly what good open source foundations do. I take it you are unfamiliar with the apache web server project?
Some OSS works on the model of selling services, some works on the model of selling extra features and commercial licenses. Personally I'm agnostic as to which is best, but this is not a new or unusual development. Many companies from Ubuntu to Firefox do commercial deals and request money indirectly or directly to support their product. If you don't like those deals or disagree with the particular method used, you can use other software, but whining about it is not productive.
Why? It seems like a pretty reasonable solution to me.
Many people seem to consider an offence that other developers need to make a living, instead of being grateful of being able to sell stuff using software they haven't paid a dime for.
Then become outraged when the developers come to the conclusion that the baker won't sell bread for pull requests.
This is what moved me into the direction of suggesting dual license for open source projects, every time someone consults me on it.
There is nothing wrong with making money, but don't to it with sleazy tactics like this that put you in a conflict of interest. Charge for support or a hosted version, but don't artificially cripple the software. If you do want to go that way, don't be open source at all because you are just a leech on the community.
I am all for charging for support or hosted versions. However this usually only suits server side software or developer tools. There are plenty more of other types of software.
What I dislike are the companies that just use FOSS as free beer, specially in closed source products or behind SaaS walls.
So when asked for advice what type of license one should give to their projects, my recommendation is always to go GPL for open source projects. If the developer community gets contacted by commercial vendors, then either create a special license for the respective vendor, or have a general one for those type of cases.
But always use a license that prevents people selling your work as theirs.
Just for the records: http://www.ohloh.net/p/nginx http://www.ohloh.net/p/nginx/contributors/summary
Indeed there are useful patches/bugfixes from the community, however nginx has always been almost a "one-man operation".
To the best of my knowledge, syslog code in nginx plus isn't based on any 3rd party work too.
The author goes out of his/her way to pick out what's wrong with NGINX due to the inadequate SAN infrastructure and at the end suggests someone else fork the project so his/her company can continue to milk the free software of the backs of others.
It's somewhat disgusting.
Wrong. NGINX has recognized this as a problem and discovered apache solved it years ago for a reason. So they decided to play catch-up, but charge for it.
>company can continue to milk the free software of the backs of others.
>It's somewhat disgusting.
That's FOSS. If you don't like it, don't use it. What NGINX is doing is disgusting. The FOSS community actively invested in NGINX via external patches, documentation, bug reports, how-to's, chef-scripts, etc and NGINX is paying everyone back by charging for features.
I don't have any problems with the author's discussion on the issue's with NGINX, but the solution to the problem is not to say its time for a fork and for a better product to come along. That's pretty much an ultimatum type argument and no one likes that.
Especially if the author has no stake in the actual development. It's one thing for Linus Torvalds to be abrasive (he's earned the right) versus being abrasive without any real foundation (I didn't get the impression that the author is a strong contributor to the project).
Well, there's a fork of nginx called Tengine, made by the Taobao folks:
http://tengine.taobao.org/document/http_log.html
No one is going to dump NGINX over this. If it is this mission critical to your business, pony up and pay for NGINX.
> We’re using php-fpm anyway; the performance difference between nginx and httpd in this scenario is negligible.
So why are we even having this discussion? Honestly if you're experiencing that much traffic and PHP performance is hindering you, you should consider some sort of Varnish full-page caching anyhow. Disk writes, as you note, are not your primary issue, and certainly is no reason to dump NGINX.
His post seems to contradict that. People will dump products for very trivial reasons if marketed correctly.
The whole tone of the blog post is passive-aggressive, whether directed at the makers of nginx (for wanting to get paid), or at the end, towards some hypothetical people who take it upon themselves to build a fork that suits all his needs (despite his not actually needing such a fork). Such a tone suggests that he feels powerless.
You have the source, patch/fork it. If you're too lazy/not skilled enough, switch to Apache and don't tell us about it.
syslog is still blocking though.
The world has gone crazy.
>> It turned out that it’s a false claim. Apache 2.4 is actually much slower than Nginx!
1: https://httpd.apache.org/docs/current/mod/event.html
No your point doesn't stand, your point is completely wrong because you don't know what you're talking about. Go back read the crap you wrote before claiming your point still stands.
Also, as an aside, it seems like the author of the post pays for NetApp and the very, very expensive support contracts that come with it, nginx contracts are a walk in the park, financially, in comparison.
The author presumably belongs to the same cohort who download films and music without paying and sneers "how you feed yourself isn't my problem, go sell some t-shirts or something". I doubt the author gives a shit, they just want stuff for free, so they can continue to make money with it.
"Poe's law, named after its author Nathan Poe, is an Internet adage reflecting the idea that without a clear indication of the author's intent, it is difficult or impossible to tell the difference between an expression of sincere extremism and a parody of extremism."
Edit: excerpt
"Logging to syslog is available as part of our commercial subscription only."
http://nginx.org/en/docs/ngx_core_module.html#error_log
http://viewdns.info/reverseip/?host=www.hipyoungstartup.com&...
The three other websites mention the same people so it's fair to say the fourth is just another project of theirs.
Use whatever fits your needs, just because it didn't fit your needs doesn't mean you should go forcing your opinion upon others. Many people including myself have had nothing but great experiences using NGINX and I don't actually see any real argument here to stop using NGINX.
Based on the tone of the article I get the kind of vibe that the author has the "I liked this band before they became mainstream" mentality about software. NGINX deserves all of the money they can get, they have a great product that is worth paying for and it's quite usuable without paying a cent, so I don't understand what there is to complain about.
http://httpd.apache.org/
Almost nobody cares about it, except the sort of place doing > tens of millions of requests per day. The sort of place that might have some money and the scale to realise that a few thousand bucks is cheaper than a bunch of engineer time.
It's a good case study in smart pricing.
>I don’t blame NGINX for wanting money in exchange for what is admittedly amazing software. I just don’t want any part of it.
Why not? You're using this awesome software whose value you appreciate and which is, you admit, open source. It's just not convenient enough for you. So why can't you pony up the money for your huge, high-traffic website?
>Yep, they took a feature that Apache httpd has had literally forever and put it behind a pay wall.
Charging for support is one thing, but this seems like it should be a basic feature.
And if I were running a server farm on FOSS software and then realized I'd need to cough up ($1350 * ~100) around $135k for the ability to disable obnoxious behavior, because the corporation arbitrarily decided that this particular feature (that most every other HTTP daemon worth a crap has had for ages) was the one that they're going to require you to pay for, I'd be a bit scandalized too, probably enough to write a blog post about how much it annoyed me.
If you want to use Apache, use Apache. That's totally your right. Or you can fork NGINX and do whatever you want. It's even got a BSDish license to make that easy. You could even use the last version of the software that baked this feature into the standard distro. But you're using the official NGINX distro for a reason, and I don't see why the people who make it shouldn't demand a bunch of money for whatever that reason is.
To be clear, it's perfectly fine to say, "I don't think this is a good feature to put behind the paywall." I'm just balking at the whiny and entitled tone of the original post. "How dare they ask me to pay for the things I want!" If I were trying to monetize an open source project, per Jacques's comment above, this is exactly the kind of high-scale feature I'd target for that.
And you would be an anchor dragging the project down. You aren't considering the angle of external contributors. As someone who submits patches to open source projects, I would be pretty damn pissed if the project I spent hours/days/weeks learning the architecture of pulled some shit like this. Especially if they rejected a patch because the feature in the patch was too 'useful'. Disgusting.
How long do you think you will keep getting external contributors when they can't even use the full software and are afraid to put the work into patches because they might conflict with the 'enterprise offering'?
If you open source something and allow external contributors, you are going to receive this entitled tone when you pull these shenanigans.
That's a good point, and I agree. But that's not the perspective being presented by this article, as far as I can tell.
Then why the angst? This just makes me more confused about what your argument is.
Perhaps in the next version it will be free for up to 20 concurrent connections and then $1 for each one after that.
From the post:
>admittedly amazing software
It sounds, honestly, like you're never going to pay for OSS. That's fine if that's the way you want to do things, but to then write a post entitled "We should ditch NGINX" seems way over the top.
Second, the entire point of open source software and the FOSS movement is that you shouldn't be extorted for functionality. Do you harass people that file bug reports or submit requests for features to the Linux Kernel for not paying?
Second: extortion, really? Thats what you're calling this, in the same breath as admitting that you won't/can't/are unwilling to pay for software that is a key part of the production line?
The people who write the software can do whatever the hell they want, as can the people using the software, as long as they abide by the licence. These are the only stipulations. Even RMS supports the right of creators to sell software.
People who write FOSS software aren't required to be a charity...
I think this is a point so many users of FOSS miss. I'm an ardent supporter of FOSS, but I don't get to act entitled unless I'm paying someone (and probably not even then).
So use Apache or any other HTTPD. Problem solved.
In this case, if they kept the same setup, I can see that it would be prohibitively expensive to pay for nginx plus on every single one of those VMs. I'm not sure of the nginx's license terms but if they count VMs as a separate server - probably a no go.
A better solution might be to turn all those VMs into application servers and put a big meaty nginx reverse proxy in front of them; that sounds like it would reduce the nginx bill but could be an awful lot of work. Then again, I presume they have automation, you'd hope so with hundreds of VMs...
My point is that it's likely not quite as simple as a grand a year, which would likely be a no-brainer if it was a site license.
I'm slightly less happy about the HTTP live streaming being in the Plus package, though. I've been playing around a lot with a media app using HLS and I can't even trial using nginx for it - not that I'd be too happy paying $1300 a year since I don't have a single user yet. I can see how they are trying to get money out of the big streaming companies, but it's not too friendly to the little guy.
Probably because you are not a systems engineer. Did you see what it resulted in here? Many of the people who have systems large enough to hit these issues will just work around it using the ramfs approach or by just dumping nginx. Either way you have a skilled engineer disappointed in your product.
Don't differentiate FOSS with paid on something that simple, especially something that has been supported by apache for almost a decade.
second, I think, at least for me, what bugs me is the massive entitlement on display. God forbid devs who built an awesome piece of software get paid; instead, dude whinges on the internet that he might have to gasp patch and compile an rpm or fork out some money. The horrors!
On the surface yes, but consider the betrayal to all of the external contributors. Is the money going to them too? What about the people that wasted time proposing a patch that overlapped with this 'enterprise feature'. Open source is not a one-way street.
While I find the wholesale re-licensing of the codebase under a commercial license reprehensible, I agreed to that before committing code. That leaves me with one remedy, not committing additional code.
As a side note, this project had a basic FOSS version and an enterprise version with additional functionality. The only part of what they did that I took issue with is re-licensing the FOSS portion under a commercial license. Had they left the FOSS portion under the OSS license and simply added commercial code on top I would have 100% continued to commit patches.
Some people are just jerks. They're the same people who are problem customers for products they pay for too, and probably the same people cutting you off in traffic and not tipping their waiter when they go out to dinner.
The 'screw you contributors' is a common argument used by self-entitled users to try and shame core maintainers into continuing to devote all their future efforts, giving away all their future time and IP away for free - just so they can continue their unfettered use of everything they make, and for them to continue to provide support, so that end-user commercial products can continue to benefit from all their future efforts, uncompensated.
Sure, I quibble with their approach to a commercial model, but I really think this is a case of "me thinks she doth protest too much" in both the literal and implied meaning.
Be careful with high performance expectations on named pipes. The fifo is in memory, but the inode is on disk. It really sucks to block on stat() and friends when you dont expect it. Oh! And those FIFOs act as a 64kb buffer. Need more buffering? Put another pipe on it!
If you are really worried about buffering, you can always have a consumer of the named pipe with its own buffering before writing to syslog (yes, that can get ugly).
In a perfect world, I'd actually prefer to write to a ring buffer in shared memory (one per worker to avoid too much contention) and then have another process that empties it as fast as it can.
Either way, it's actually not that hard to hack in to nginx. If someone were to contribute a patch that did logging the "right" way and host it on say... github, I think you'd find the nginx commercial folks would have a response that works out pretty well for everyone. The catch is, it requires someone to do something.
In reality though, you can always fork, which puts pressure on them to embrace desirable patches if they are provided from outside, and to move their enterprise features into the main branch. If they keep stuff out of the their main branch that people can route around, it significantly reduces the commercial value they can realize.
access_log /dev/nginx_access log_format_name buffer=64k flush=10s;
Since this is a pipe there is still some blocking IO, but no worse off then writing to local file.
The way we are migrating will be non-blocking IO through the use of Lua Resty log module ( https://github.com/cloudflare/lua-resty-logger-socket ).
We will write up a blog post at some point but hopefully this is useful to you. In the future we are going to be going one step further and have NGINX emit protobuff files. Feel free to email dane AT cloudflare.com if you have any questions.
http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/12...
If you had been served with a national security letter, you would be obligated to lie about it.
Plus, you have a pretty significant financial incentive to lie about how great Cloudflare is, with no downside, since you're not under oath on HN. And even if you were, officials who have lied about the extent of surveillance programs while under oath haven't been prosecuted.
Representatives of Facebook lied. Ditto with Google. Etc, etc, etc.
In that case, you can be cagy (as Google has I believe) and say something on the lines of "I can neither confirm nor deny receiving a NS letter" which of course is double speak for "I have one, and I can't talk about it directly".
http://blog.cloudflare.com/what-cloudflare-logs
TL;DR: we generate logs at the edge, those are turned into aggregates to display analytics data (e.g., page views, hits, bandwidth), then logs are discarded unless you're an Enterprise customer in which case we allow you to download the raw log data for 3 days.
You mean creating a http://linux.die.net/man/7/pipe and configure syslog-ng to read from it?
A very comparable configuration for apache https://peter.blogs.balabit.com/2010/02/how-to-collect-apach...
Wow, mind blowing. That's 4pb/day, 1+eb/year.
If it _were_ access log only, and your log lines average 1KB in length (pretty generous), that's 52m qps. If we take that further and assume each object is 93KB [1] then your outbound traffic is almost 40Tb/s (terabits per second).
So I assume it must be more than just access logging!
1. https://developers.google.com/speed/articles/web-metrics
[0] http://haproxy.1wt.eu/
That said, if you're looking for a proxy/load balancer, HAProxy is most likely the absolute best you're going to find anywhere, ever...and the price is right ;)
http://tengine.taobao.org/
Conveniently this would support the authors requirements of syslog feature.
A) The author is using a load balancer that can do centralised logging in a sane fashion perhaps they can turn off end logging on nginx all together.
B) The author has looked in to the Lua nginx scripting capabilities for direct logging without touching disk.
C) Place a greater emphasis on SaaS logging with javascript on the client side.
It sounds as if their architecture needs a massive re-think.
Nginx is a great piece of software for $no dollars, maybe it would be good karma to pay for the extras you need?
For that price, they could pay someone who's sole job is to maintain a private fork with the feature. It's not like they can submit it back since nginx would reject an enterprise competing patch, but at least they would have the functionality and the benefit of another dev on hand.